One is part of the client which is only suppose to be used by app developers. The other is part of the server for server to server synchs using subscription. Something in jboss is doing a classpath/reflection scan for anything that has @WebService on it and attempting to start it up. On older Jboss versions, it only did that if the service also had an ejb.stateless flag on it. In the case of juddiv3.war, we explicitly define what it start via either beans.xml or web.xml.
Is there a way to prevent the jboss scanner for this war? On Wed, Jan 29, 2014 at 8:50 AM, Jesse Sightler <[email protected]> wrote: > ./juddi-core/src/main/java/org/apache/juddi/api/impl/UDDISubscriptionListenerImpl.java > ./juddi-client/src/main/java/org/apache/juddi/v3/client/subscription/SubscriptionCallbackListener.java > > Unless I am misreading the code, they both seem to represent the same > service, and both are included in juddiv3.war. > > > On Wed, Jan 29, 2014 at 8:41 AM, Kurt T Stam <[email protected]> wrote: >> >> On 1/28/14, 3:40 PM, Jesse Sightler wrote: >> >> Is there any work on getting this to use a JPA implementation that is >> supported directly in JBoss again (Hibernate)? >> >> Hi Jesse, there is a bug in Hibernate that is fixed in Hibernate 4.3.1+, >> see >> https://issues.apache.org/jira/browse/JUDDI-587 >> >> When I looked at it last it looked like we need to upgrade to JPA2.0 and >> we scheduled it for 3.2.1, if you have time to take a look at it we may be >> able to pull it back into the 3.2.0 release. Maybe we can use to workaround >> stated in JUDDI-587 to r emove the "id" from the ordering. >> >> >> JBoss' JAXR is disabled, the two implementations appear to be in JUDDI >> itself. >> >> I've not seen that before.. what are the steps you followed to build and >> deploy? There should only be one CallBack. That said, since we do allow >> using multiple juddi-clients in one JVM maybe we can add a postfix to the >> name to make it unique so it won't clash. I'll look into that. >> >> >> >> On Tue, Jan 28, 2014 at 3:36 PM, Kurt T Stam <[email protected]> wrote: >>> >>> Hi Jesse, >>> >>> 1. The juddiv3.war has a openjpa-jboss7up profile that you can use to >>> create juddiv3 war targeted for AS7/EAP6. >>> >>> And we have some notes here: >>> >>> https://github.com/UDDI/juddi/wiki/GuideDeployingtoJBoss7 >>> >>> 2. I think it is the org.jboss.as.jaxr module registering the other >>> UDDISubscriptionListener? Just disable that for now. >>> >>> --Kurt >>> >>> >>> >>> On 1/28/14, 3:08 PM, Jesse Sightler wrote: >>> >>> Is this something that is being actively tested and maintained? I am >>> trying it with EAP 6.1.1, and receiving an error on deployment: >>> >>> >>> /juddi/src/server/jboss-eap-6.1/standalone/deployments/juddiv3.war/WEB-INF/lib/jaxb-impl-2.2.6.jar >>> does not point to a valid jar for a Class-Path reference. >>> 15:03:46,166 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) >>> MSC000001: Failed to start service >>> jboss.deployment.unit."juddiv3.war".PARSE: >>> org.jboss.msc.service.StartException in service >>> jboss.deployment.unit."juddiv3.war".PARSE: JBAS018733: Failed to process >>> phase PARSE of deployment "juddiv3.war" >>> at >>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127)[jboss-as-server-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] >>> at >>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) >>> [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] >>> at >>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) >>> [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> [rt.jar:1.7.0_51] >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> [rt.jar:1.7.0_51] >>> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] >>> Caused by: java.lang.IllegalArgumentException: JBAS015533: Web Service >>> endpoint org.apache.juddi.api.impl.UDDISubscriptionListenerImpl with URL >>> pattern /UDDISubscriptionListenerService is already registered. Web service >>> endpoint >>> org.apache.juddi.v3.client.subscription.SubscriptionCallbackListener is >>> requesting the same URL pattern. >>> at >>> org.jboss.as.webservices.metadata.model.AbstractDeployment.addEndpoint(AbstractDeployment.java:60) >>> at >>> org.jboss.as.webservices.metadata.model.JAXWSDeployment.addEndpoint(JAXWSDeployment.java:27) >>> at >>> org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_POJO.processAnnotation(WSIntegrationProcessorJAXWS_POJO.java:105) >>> at >>> org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:92) >>> at >>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120)[jboss-as-server-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] >>> ... 5 more >>> >>> >>> It seems to me that this service is actually declared twice, so I am not >>> sure how it is supposed to work. >>> >>> Is Tomcat the only supported container at this point? >>> >>> >> >> >
