[ 
https://issues.apache.org/jira/browse/SCOUT-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057677#comment-13057677
 ] 

subes commented on SCOUT-107:
-----------------------------

Hi Kurt,

I would prefer to keep the constants or at least provide them somewhere else. 
See a bit of reasoning here: http://www.jpox.org/servlet/jira/browse/NUCCORE-718

*quote*
This makes development easier, because:
1. brings in type safety when using the constants instead of string literals, 
thus during datanucleus upgrades immediately detecting changed/removed hints 
through compiler errors.
2. it is an easy to find reference for available query hints, thus not having 
to memorize the strings and not needing to look them up in the documentation on 
the datanucleus website.
*quote*

As for documentation, I did not write down anything specifically while doing 
this except for these bug reports. The JBoss docs were quite handy, but 
outdated. I think the relevant information for me was, which binding mechanism 
to use (only juddi-client working properly) and how to get juudi to work with 
scout properly.

I've attached the relevant parts of my scout integration module. It won't work 
for anyone else, because it relies on a REST service on the registry service 
module to determine if the service is started properly and thus calls via jaxr 
don't mess things up during startup. Also the @Retry annotation aspect is not 
included, which retries on IOExceptions with incremental delays. Also the 
properties classes are not provided. Anyway this gives a view on how I am using 
scout and how to integrate scout with a spring DestinationProvider 
(http://static.springsource.org/spring-ws/sites/1.5/apidocs/org/springframework/ws/client/support/destination/DestinationProvider.html).
I just found out there is an AbstractCachingDestinationProvider 
(http://static.springsource.org/spring-ws/site/apidocs/org/springframework/ws/client/support/destination/AbstractCachingDestinationProvider.html)
 which I might integrate in the near time as a base class for my 
RegistyDestinationProvider.

Cheers,

--subes

> fix constants in org.apache.ws.scout.registry.RegistryV3Impl for uddi 3
> -----------------------------------------------------------------------
>
>                 Key: SCOUT-107
>                 URL: https://issues.apache.org/jira/browse/SCOUT-107
>             Project: Scout
>          Issue Type: Bug
>          Components: Scout Implementation
>    Affects Versions: 1.2.2
>            Reporter: subes
>            Assignee: Kurt T Stam
>             Fix For: 1.2.4
>
>
> in  org.apache.ws.scout.registry.RegistryV3Impl these constants are defined:
> public static final String DEFAULT_INQUIRY_ENDPOINT = 
> "http://localhost/juddi/inquiry";;
> public static final String DEFAULT_PUBLISH_ENDPOINT = 
> "http://localhost/juddi/publish";;
> public static final String DEFAULT_SECURITY_ENDPOINT = 
> "http://localhost/juddi/security";;
> public static final String DEFAULT_ADMIN_ENDPOINT = 
> "http://localhost/juddi/admin";;
> public static final String DEFAULT_TRANSPORT_CLASS = 
> "org.apache.ws.scout.transport.AxisTransport";
> public static final String DEFAULT_SECURITY_PROVIDER = 
> "com.sun.net.ssl.internal.ssl.Provider";
> public static final String DEFAULT_PROTOCOL_HANDLER = 
> "com.sun.net.ssl.internal.www.protocol";
> public static final String DEFAULT_UDDI_VERSION = "2.0";
> public static final String DEFAULT_UDDI_NAMESPACE = "urn:uddi-org:api_v2";
> Those are just copy-pasted from org.apache.ws.scout.registry.RegistryImpl and 
> don't fit for juddi 3, but are still for juddi 2.
> Corrected those constants should be:
> public static final String DEFAULT_INQUIRY_ENDPOINT = 
> "http://localhost//juddiv3/services/inquiry";;
> public static final String DEFAULT_PUBLISH_ENDPOINT = 
> "http://localhost/juddiv3/services/publish";;
> public static final String DEFAULT_SECURITY_ENDPOINT = 
> "http://localhost//juddiv3/services/security";;
> public static final String DEFAULT_ADMIN_ENDPOINT = 
> "http://localhost/juddiv3/services/juddi-api";;
> public static final String DEFAULT_TRANSPORT_CLASS = 
> "org.apache.ws.scout.transport.AxisTransport";
> public static final String DEFAULT_SECURITY_PROVIDER = 
> "com.sun.net.ssl.internal.ssl.Provider";
> public static final String DEFAULT_PROTOCOL_HANDLER = 
> "com.sun.net.ssl.internal.www.protocol";
> public static final String DEFAULT_UDDI_VERSION = "3.0";
> public static final String DEFAULT_UDDI_NAMESPACE = "urn:uddi-org:api_v3";
> Though, i don't know if AxisTransport has to get those values for the urls 
> actually:
> public static final String DEFAULT_INQUIRY_ENDPOINT = 
> "http://localhost//juddiv3/services/inquiry?wsdl";;
> public static final String DEFAULT_PUBLISH_ENDPOINT = 
> "http://localhost/juddiv3/services/publish?wsdl";;
> public static final String DEFAULT_SECURITY_ENDPOINT = 
> "http://localhost//juddiv3/services/security?wsdl";;
> public static final String DEFAULT_ADMIN_ENDPOINT = 
> "http://localhost/juddiv3/services/juddi-api?wsdl";;
> Which are actually set in my uddi.xml for juddi-client 3.0.4. Actualy I could 
> not get AxisTransport to run so i switched to LocalTransport and set the 
> proper juddi-client classes as the endpoint.
> -------------------------------------------------------------
> Maybe you should make this setup with juddi-client doing the actual 
> communication default for uddi 3? I got that idea from 
> http://docs.redhat.com/docs/en-US/JBoss_Enterprise_SOA_Platform/5/html/ESB_Services_Guide/chap-the_registry.html#sect-SOA_ESB_Services_Guide-Configuring_the_Registry-Using_Scout_and_jUDDI
>  (outdated because the classes are for juddi-client 2 and changed in 
> juddi-client 3, though they talk about juddi-client 3 needed in the classpath 
> at the end).The properties for this setup would be:
> public static final String DEFAULT_INQUIRY_ENDPOINT = 
> "org.apache.juddi.v3.client.transport.wrapper.UDDIInquiryService#inquire";
> public static final String DEFAULT_PUBLISH_ENDPOINT = 
> "org.apache.juddi.v3.client.transport.wrapper.UDDIPublicationService#publish";
> public static final String DEFAULT_SECURITY_ENDPOINT = 
> "org.apache.juddi.v3.client.transport.wrapper.UDDISecurityService#secure";
> public static final String DEFAULT_ADMIN_ENDPOINT = 
> "http://localhost/juddiv3/services/juddi-api";; //actually i dont know about 
> this, because it seems it isnt even used when having juddi-client?
> public static final String DEFAULT_TRANSPORT_CLASS = 
> "org.apache.ws.scout.transport.LocalTransport";
> public static final String DEFAULT_SECURITY_PROVIDER = 
> "com.sun.net.ssl.internal.ssl.Provider";
> public static final String DEFAULT_PROTOCOL_HANDLER = 
> "com.sun.net.ssl.internal.www.protocol";
> public static final String DEFAULT_UDDI_VERSION = "3.0";
> public static final String DEFAULT_UDDI_NAMESPACE = "urn:uddi-org:api_v3";
> If this is too much, I would be happy if you just fixed these two constants:
> public static final String DEFAULT_UDDI_VERSION = "3.0";
> public static final String DEFAULT_UDDI_NAMESPACE = "urn:uddi-org:api_v3";
> So I can use the correct constants from 
> org.apache.ws.scout.registry.RegistryV3Impl for these two properties instead 
> of defining them in my code as string literals.
> Finding the correct values was also quite hard :). Found them by browsing the 
> scout sources 
> http://svn.apache.org/viewvc/juddi/scout/trunk/src/test/resources/scoutv3.properties-example?view=markup
> ----------------------------------------------------------------
> As a benchmark, it took me as a uddi and jaxr newb three days to get this 
> setup working and integrated into my software product line project. Scout is 
> an important and good project, but it could be a bit more robust and user 
> friendly. ;)
> Documentation on this subject at all is quite sparse, which made this quite 
> hard to get done.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to