It looks like it could be excluded: https://community.jboss.org/thread/215838
On Wed, Jan 29, 2014 at 9:02 AM, Alex O'Ree <spyhunte...@gmail.com> wrote: > 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 > <jesse.sight...@gmail.com> 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 <kurt.s...@gmail.com> > 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 <kurt.s...@gmail.com> > 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? > >>> > >>> > >> > >> > > >
