https://issues.apache.org/jira/browse/JUDDI-828
On Thu, Jan 30, 2014 at 12:01 PM, Kurt T Stam <[email protected]> wrote: > Great :), Can you open a jira and add this link? > > Thx, > > --Kurt > > > On 1/30/14, 11:58 AM, Jesse Sightler wrote: > > I've sent a PR with the changes to support OpenJPA on EAP6.x easily: > https://github.com/apache/juddi/pull/1 > > > > On Wed, Jan 29, 2014 at 9:09 AM, Jesse Sightler > <[email protected]>wrote: > >> 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 <[email protected]>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 >>> <[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? >>> >>> >>> >>> >>> >> >>> >> >>> > >>> >> >> > >
