Hide Forgot
Affects: Release Notes Date of First Response: 2009-10-19 06:04:34 Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/354553 Workaround: Workaround Exists Workaround Description: run.sh -Djava.naming.provider.url= (url is empty) project_key: SOA If you configure binding-manager to change the value of java.naming.provider.url (e.g. jnp://${jboss.esb.bind.address}:1199), JNDIRegistration will throw Exception during start-up because JNDIRegistration uses default value of java.naming.provider.url. Even if you edit deploy/jbossesb.sar/esb.juddi.xml directly instead of binding-manager, result will be the same. 17:26:26,107 INFO [JuddiRMIService] starting juddi RMI service 17:26:31,134 ERROR [STDERR] javax.naming.CommunicationException: Could not obtain connection to any of these urls: localhost:1099 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server localhost:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost:1099 [Root exception is java.net.ConnectException: Connection refused]]] 17:26:31,135 ERROR [STDERR] at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1562) 17:26:31,135 ERROR [STDERR] at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:487) 17:26:31,135 ERROR [STDERR] at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:480) 17:26:31,135 ERROR [STDERR] at javax.naming.InitialContext.rebind(InitialContext.java:367) 17:26:31,135 ERROR [STDERR] at org.apache.juddi.registry.rmi.JNDIRegistration.register(JNDIRegistration.java:95) 17:26:31,136 ERROR [STDERR] at org.jboss.internal.soa.esb.dependencies.JuddiRMIService.startService(JuddiRMIService.java:112) According to JBESB-2373 and SOA-1487, this is an intended change from SOA-P 4.3.0.GA_CP01, but org.apache.juddi.util.Config doesn't seem to be properly initialized in this case. How to reproduce: - Install SOA-P 4.3.0.GA CP02 - Uncomment mbean org.jboss.services.binding.ServiceBindingManager in conf/jboss-service.xml - Start JBoss
jUDDI is incorrectly overriding the JNDI defaults, rather than allowing InitialContext to do the work.
The jmx-console shows the following properties being set by default java.naming.factory.initial: org.jnp.interfaces.NamingContextFactory java.naming.factory.url.pkgs: org.jboss.naming:org.jnp.interfaces The lack of java.naming.provider.url results in juddi guessing at the correct value, getting it wrong in this instance.
Changed workaround
Workaround Description: Removed: Set system properties. Example) > bin/run.sh -c default -Djava.naming.provider.url=jnp://localhost:1199 Added: run.sh -Djava.naming.provider.url= (url is empty)
Fixed Description from "because JNDIRegistration uses java.naming.provider.url from system properties." to "because JNDIRegistration uses default value of java.naming.provider.url."
Link: Added: This issue related JBESB-2906
Link: Added: This issue related SOA-1547
Approved for SOA 4.3 CP03.
Link: Removed: This issue related JBESB-2906
Link: Added: This issue depends JBESB-3198
Updated in the ESB codebase, will be in next merge.
Draft text for the Resolved Issues section of the Release Notes states: https://jira.jboss.org/jira/browse/JBESB-3198 The JNDIRegistration did not refer to esb.juddi.xml. As a consequence, if the binding-manager was configured to change the value of java.naming.provider.url, a javax.naming.CommunicationException exception would occur. This happened because jUDDI was being loaded at the incorrect point. The JuddiRMIService needed to initialize the configuration before the Registry was created. Because it was now, jUDDI would then incorrectly override the JNDI defaults, rather than allow InitialContext to do the work. (jUDDI would attempt to guess the value of java.naming.provider.url and made mistakes.) To fix this issue, jUDDI is now loaded at the correct point. The value is now populated correctly and, as a result, the exception no longer occurs.
Verified in 4.3.CP03 ER1