Attachment: Added: juddi_subscriptions.zip
Attachment: Added: server1.log
Attachment: Added: server2.log

Attachment: Removed: juddi_subscriptions.zip 

Attachment: Added: juddi_subscriptions.zip

TomC is looking into this and this might be a juddi issue but we are not sure yet.

TomC and I have been looking into this issue and I'm posting our joint findings so far.

Stacktrace:
2010-02-21 09:55:58,991 DEBUG [org.jboss.ws.core.utils.JBossWSEntityResolver] (RMI TCP Connection(5)-127.0.0.1) resolveEntity: [pub=http://127.0.0.1:8180/juddiv3/services/security?wsdl&resource=ud
di_v3.xsd,sysid=http://127.0.0.1:8180/juddiv3/services/security?wsdl&resource=uddi_v3.xsd]2010-02-21 09:55:58,992 TRACE [org.jboss.util.xml.JBossEntityResolver] (RMI TCP Connection(5)-127.0.0.1) resolvePublicID, publicId=http://127.0.0.1:8180/juddiv3/services/security?wsdl&resource=udd
i_v3.xsd
2010-02-21 09:55:58,992 TRACE [org.jboss.util.xml.JBossEntityResolver] (RMI TCP Connection(5)-127.0.0.1) resolveSystemID, systemId=http://127.0.0.1:8180/juddiv3/services/security?wsdl&resource=udd
i_v3.xsd
2010-02-21 09:55:58,992 TRACE [org.jboss.util.xml.JBossEntityResolver] (RMI TCP Connection(5)-127.0.0.1) resolveClasspathName, systemId=http://127.0.0.1:8180/juddiv3/services/security?wsdl&resourc
e=uddi_v3.xsd
2010-02-21 09:55:58,992 TRACE [org.jboss.util.xml.JBossEntityResolver] (RMI TCP Connection(5)-127.0.0.1) Mapped systemId to filename: security
2010-02-21 09:55:58,992 TRACE [org.jboss.util.xml.JBossEntityResolver] (RMI TCP Connection(5)-127.0.0.1) security maps to URL: vfszip:/Users/danbev/work/jboss/soa-p/jboss-soa-p.5.0.0/jboss-as/comm
on/lib/jboss-ejb3-core.jar/security/
2010-02-21 09:55:58,994 ERROR [STDERR] (RMI TCP Connection(5)-127.0.0.1) [Fatal Error] security?wsdl&resource=uddi_v3.xsd:1:1: Content is not allowed in prolog.
2010-02-21 09:55:58,994 ERROR [org.apache.juddi.v3.client.config.XRegistration] (RMI TCP Connection(5)-127.0.0.1) Could not  xregister entityKey: uddi:marketing.apache.org:new-service-1 + from RemotehostCratchit to LocalhostCratchit. javax.wsdl.WSDLException: WSDLException (at /definitions/types/xsd:schema): faultCode=PARSER_ERROR: Problem parsing 'http://127.0.0.1:8180/juddiv3/services/se
curity?wsdl&resource=uddi_v3.xsd'.: org.xml.sax.SAXParseException: Content is not allowed in prolog. org.jboss.ws.metadata.wsdl.WSDLException: javax.wsdl.WSDLException: WSDLException (at /definiti
ons/types/xsd:schema): faultCode=PARSER_ERROR: Problem parsing 'http://127.0.0.1:8180/juddiv3/services/security?wsdl&resource=uddi_v3.xsd'.: org.xml.sax.SAXParseException: Content is not allowed i
n prolog.
org.apache.juddi.v3.client.transport.TransportException: javax.wsdl.WSDLException: WSDLException (at /definitions/types/xsd:schema): faultCode=PARSER_ERROR: Problem parsing 'http://127.0.0.1:8180/
juddiv3/services/security?wsdl&resource=uddi_v3.xsd'.: org.xml.sax.SAXParseException: Content is not allowed in prolog.
    at org.apache.juddi.v3.client.transport.JAXWSTransport.getUDDISecurityService(JAXWSTransport.java:104)
    at org.apache.juddi.v3.client.config.UDDIClerk.getAuthToken(UDDIClerk.java:197)
    at org.apache.juddi.v3.client.config.UDDIClerk.findService(UDDIClerk.java:164)
    at org.apache.juddi.v3.client.config.XRegistration.xRegisterService(XRegistration.java:61)
    at org.apache.juddi.api.impl.XRegisterHelper.handle(XRegisterHelper.java:39)
    at org.apache.juddi.api.impl.JUDDIApiImpl.invokeSyncSubscription(JUDDIApiImpl.java:564)
    at org.apache.juddi.rmi.JUDDIApiService.invokeSyncSubscription(JUDDIApiService.java:105)
    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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
    at sun.rmi.transport.Transport$1.run(Transport.java:159)
   at java.security.AccessController.doPrivileged(Native Method)
    at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
    at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
    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:637)
Caused by: org.jboss.ws.metadata.wsdl.WSDLException: javax.wsdl.WSDLException: WSDLException (at /definitions/types/xsd:schema): faultCode=PARSER_ERROR: Problem parsing 'http://127.0.0.1:8180/juddiv3/services/security?wsdl&resource=uddi_v3.xsd'.: org.xml.sax.SAXParseException: Content is not allowed in prolog.
    at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:155)
    at org.jboss.ws.metadata.umdm.ServiceMetaData.getWsdlDefinitions(ServiceMetaData.java:293)
    at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:84)
    at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:137)
    at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
    at javax.xml.ws.Service.<init>(Service.java:79)
    at javax.xml.ws.Service.create(Service.java:96)
    at org.apache.juddi.v3.client.transport.JAXWSTransport.getUDDISecurityService(JAXWSTransport.java:101)
    ... 20 more
Caused by: javax.wsdl.WSDLException: WSDLException (at /definitions/types/xsd:schema): faultCode=PARSER_ERROR: Problem parsing 'http://127.0.0.1:8180/juddiv3/services/security?wsdl&resource=uddi_v3.xsd'.: org.xml.sax.SAXParseException: Content is not allowed in prolog.
    at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.getDocument(JBossWSDLReaderImpl.java:2138)
    at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.parseSchema(JBossWSDLReaderImpl.java:833)
    at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.parseSchema(JBossWSDLReaderImpl.java:657)
    at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.parseTypes(JBossWSDLReaderImpl.java:618)
    at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.parseDefinitions(JBossWSDLReaderImpl.java:330)
    at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.readWSDL(JBossWSDLReaderImpl.java:2292)
    at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.readWSDL(JBossWSDLReaderImpl.java:2256)
    at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.readWSDL(JBossWSDLReaderImpl.java:2309)
    at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.readWSDL(JBossWSDLReaderImpl.java:2330)
    at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.readWSDL(JBossWSDLReaderImpl.java:2362)
    at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:128)
    ... 27 more
Caused by: org.xml.sax.SAXParseException: Content is not allowed in prolog.
    at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
    at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
    at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.getDocument(JBossWSDLReaderImpl.java:2128)
    ... 37 more


What is happening?
The source that is being parse by DOMParser.parse is actually:
?v5;?9;;
tst.policygrant {
        permission java.security.AllPermission;
};
PK

?v5;?9;;

This can be found by setting a breakpoint in JBossWSDLReaderImpl line 2128
You can use the following code in Eclipse's Display View:
java.io.InputStream in = inputSource.getByteStream();
java.io.ByteArrayOutputStream out = new java.io.ByteArrayOutputStream();
int read;
while ( (read = in.read()) != -1)
{
    out.write(read);
}
System.out.println(new String(out.toByteArray()));

Note that the output will be in the servers console window.

The question is were is this output coming from?
It turns out that this comes from JBossEntityResolver and if you turn on TRACE logging for org.jboss.util.xml you'll see more information in the server's server.log:
2010-02-21 10:35:13,417 TRACE [org.jboss.util.xml.JBossEntityResolver] (RMI TCP Connection(9)-127.0.0.1) resolvePublicID, publicId=http://127.0.0.1:8080/juddiv3/services/security?wsdl&resource=uddi_v3.xsd
2010-02-21 10:35:13,417 TRACE [org.jboss.util.xml.JBossEntityResolver] (RMI TCP Connection(9)-127.0.0.1) resolveSystemID, systemId=http://127.0.0.1:8080/juddiv3/services/security?wsdl&resource=uddi_v3.xsd
2010-02-21 10:35:13,417 TRACE [org.jboss.util.xml.JBossEntityResolver] (RMI TCP Connection(9)-127.0.0.1) resolveClasspathName, systemId=http://127.0.0.1:8080/juddiv3/services/security?wsdl&resource=uddi_v3.xsd
2010-02-21 10:35:13,417 TRACE [org.jboss.util.xml.JBossEntityResolver] (RMI TCP Connection(9)-127.0.0.1) Mapped systemId to filename: security
2010-02-21 10:35:13,418 TRACE [org.jboss.util.xml.JBossEntityResolver] (RMI TCP Connection(9)-127.0.0.1) security maps to URL: vfszip:/Users/danbev/work/jboss/soa-p/jboss-soa-p.5.0.0/jboss-as/common/lib/jboss-ejb3-core.jar/security/
2010-02-21 10:35:13,419 ERROR [STDERR] (RMI TCP Connection(9)-127.0.0.1) [Fatal Error] security?wsdl&resource=uddi_v3.xsd:1:1: Content is not allowed in prolog.

Notice the call to resolveClasspathName with the systemId of "http://127.0.0.1:8080/juddiv3/services/security?wsdl&resource=uddi_v3.xsd". This string will be parsed to get the final path component which will be 'security'. This string will then be passed into the loadClasspathResource method. loadClasspathResource will try to load call classloader.getResource using the context classloader.
This will find a match for the common/lib/jboss-ejb3-core.jar/security/ folder. This security directory contains one file named tst.policy: 
danbev$ unzip -p common/lib/jboss-ejb3-core.jar security/tst.policy
grant {
        permission java.security.AllPermission;
};
loadClasspathResource will return an inputstream to this directory. I'm not sure if there is a case where a systemId is not a file. Perhaps there should be a check to see in loadClasspathResource to see if the url is a local file and make sure that that it is not a directory and return null. I'll try this and see if that works.

You can checkout jboss commons from https://svn.jboss.org/repos/common/common-core/tags/2.2.16.GA.

Workaround Description: Added: Workaround
A possible workaround is to change the path to /uddi/security to something like 'sec' instead.
The following files would need to be updated:

juddiv3.war/WEB-INF/wsdl:
esb_security_service.wsdl:            <soap:address location="http://localhost/uddi/security/"/>
uddi_v3_service.wsdl:            <soap:address location="http://localhost/uddi/security/"/>

juddiv3.war/WEB-INF/web.xml:
<url-pattern>/services/security</url-pattern>

jbossesb.sar/esb.juddi.client.xml
<securityUrl>http://${jboss.esb.bind.address}:8080/juddiv3/services/security?wsdl</securityUrl>

The above urls need to be changed to something different than 'security'.

Tried Daniel's workaround of changing the location of the security port - the test runs fine if you change "security" to something else (I used "juddisecurity" in my test)

changed juddiv3.war web.xml from

    <servlet-mapping>
        <servlet-name>SecurityService</servlet-name>
        <url-pattern>/services/security</url-pattern>
    </servlet-mapping>

to

    <servlet-mapping>
        <servlet-name>SecurityService</servlet-name>
        <url-pattern>/services/juddisecurity</url-pattern>
    </servlet-mapping>

and then changed the esb.juddi.client.*.xml's to match.       Also changed deploy/jbossesb-registry.sar/juddi_custom_install_data/root_BusinessEntity.xml (changed the wsdl location from security?wsdl to juddisecurity?wsdl) and removed the old hypersonic db.        After these steps, the test worked fine for me - this should be a good enough workaround to run the test for now.    

Workaround Description: Removed: Workaround
A possible workaround is to change the path to /uddi/security to something like 'sec' instead.
The following files would need to be updated:

juddiv3.war/WEB-INF/wsdl:
esb_security_service.wsdl:            <soap:address location="http://localhost/uddi/security/"/>
uddi_v3_service.wsdl:            <soap:address location="http://localhost/uddi/security/"/>

juddiv3.war/WEB-INF/web.xml:
<url-pattern>/services/security</url-pattern>

jbossesb.sar/esb.juddi.client.xml
<securityUrl>http://${jboss.esb.bind.address}:8080/juddiv3/services/security?wsdl</securityUrl>

The above urls need to be changed to something different than 'security'.
 Added: Workaround
A possible workaround is to change the path to /uddi/security to something like 'sec' instead.
The following files would need to be updated:

juddiv3.war/WEB-INF/wsdl:
esb_security_service.wsdl:            <soap:address location="http://localhost/uddi/security/"/>
uddi_v3_service.wsdl:            <soap:address location="http://localhost/uddi/security/"/>

juddiv3.war/WEB-INF/web.xml:
<url-pattern>/services/security</url-pattern>

jbossesb.sar/esb.juddi.client.xml
<securityUrl>http://${jboss.esb.bind.address}:8080/juddiv3/services/security?wsdl</securityUrl>

Also change deploy/jbossesb-registry.sar/juddi_custom_install_data/root_BusinessEntity.xml (change the wsdl location from security?wsdl to sec?wsdl) and remove the old hypersonic db from <configuration>/data.

The above urls need to be changed to something different than 'security'.