juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "subes (JIRA)" <scout-...@ws.apache.org>
Subject [jira] [Commented] (SCOUT-107) fix constants in org.apache.ws.scout.registry.RegistryV3Impl for uddi 3
Date Thu, 30 Jun 2011 08:38:29 GMT

    [ 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

        

Mime
View raw message