[
https://issues.apache.org/jira/browse/JUDDI-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15006741#comment-15006741
]
Matthieu Ghilain edited comment on JUDDI-941 at 11/16/15 3:18 PM:
------------------------------------------------------------------
The problem I see (correct me if I am wrong!) is that it is not possible to
provide the properties dynamically. Is there a way to provide properties to
JUDDI otherwize than with the configuration file? There should be some kind of
plugin mechanism so that we can inject at runtime some properties inside JUDDI
configuration or provide configuration to juddi otherwize than using uddi.xml.
Therefore if I want to spawn several instances of the service I am always using
the same static configuration from the uddi.xml.
EDIT:
I have found a way to pass configuration to the UDDIClient linked to the
ServletContext but the problem is that this configuration is not passed to the
class which resolves the annotation. Only the properties of the UDDI clerk are
used. It would be more convinient to pass directly the configuration of the
UDDIClient which seems to be a combination of several property sources (System,
uddi.xml, in memory -> the one I have used to pass my custom configuration...)
was (Author: ghila...@gmail.com):
The problem I see (correct me if I am wrong!) is that it is not possible to
provide the properties dynamically. Is there a way to provide properties to
JUDDI otherwize than with the configuration file? There should be some kind of
plugin mechanism so that we can inject at runtime some properties inside JUDDI
configuration or provide configuration to juddi otherwize than using uddi.xml.
Therefore if I want to spawn several instances of the service I am always using
the same static configuration from the uddi.xml.
> Dynamic discovery of web service endpoint
> -----------------------------------------
>
> Key: JUDDI-941
> URL: https://issues.apache.org/jira/browse/JUDDI-941
> Project: jUDDI
> Issue Type: Improvement
> Components: juddi-client
> Affects Versions: 3.3.1
> Reporter: Matthieu Ghilain
> Labels: SOAP, discovery, dynamic, endpoint, juddi
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Here is the example from the JUDDI documentation:
> {code:title=HelloWorldImpl .java|borderStyle=solid}
> @UDDIService(
> businessKey="uddi:myBusinessKey",
> serviceKey="uddi:myServiceKey",
> description = "Hello World test service")
> @UDDIServiceBinding(
> bindingKey="uddi:myServiceBindingKey",
> description="WSDL endpoint for the helloWorld Service. This service is used
> for "
> + "testing the jUDDI annotation
> functionality",
> accessPointType="wsdlDeployment",
>
> accessPoint="http://localhost:8080/juddiv3-samples/services/helloworld?wsdl";)
> @WebService(
> endpointInterface = "org.apache.juddi.samples.HelloWorld",
> serviceName = "HelloWorld")
> public class HelloWorldImpl implements HelloWorld {
> public String sayHi(String text) {
> System.out.println("sayHi called");
> return "Hello " + text;
> }
> }
> {code}
> The problem with this kind of registration is that it is still static. The
> accessPoint should be resolved dynamically at runtime. Otherwise it is not
> possible to spawn new service instances dynamically and to scale. This in my
> opinion should be part of the JUDDI features.
> What do you think?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
