[jira] [Commented] (JUDDI-555) Add additional examples for working with UDDI
[ https://issues.apache.org/jira/browse/JUDDI-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599586#comment-13599586 ] Kurt T Stam commented on JUDDI-555: --- what's wrong with mvn -Pdemo test ? (less typing) > Add additional examples for working with UDDI > - > > Key: JUDDI-555 > URL: https://issues.apache.org/jira/browse/JUDDI-555 > Project: jUDDI > Issue Type: Improvement > Components: feature requests >Reporter: Alex O'Ree >Assignee: Kurt T Stam >Priority: Minor > Fix For: 3.1.5 > > Attachments: SimpleBrowserPatch.patch, > simple-create-tmodel-partition.patch > > > The included coded examples only includes publishing to a registry. The most > basic (IMO) example is to simply list everything in a registry and dump it to > console. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JUDDI-561) Transaction rollback when PersonName Lang is greater than 5 characters
[
https://issues.apache.org/jira/browse/JUDDI-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599543#comment-13599543
]
Kurt T Stam commented on JUDDI-561:
---
List of field lengths that get shorter:
addressLine keyname keyvalue, default > 255
[6:36pm] spyhunter99: BindingDesc name 1024 > 255
[6:37pm] spyhunter99: BusinessDesc 1024 > 255
[6:37pm] spyhunter99: BusinessName from default > 255
[6:38pm] KurtStam: you are quoting the length as it was defined in the java?
[6:38pm] spyhunter99: yes
[6:38pm] KurtStam: k
[6:38pm] spyhunter99: ContactDesc 1024 > 255
[6:38pm] spyhunter99: DiscoveryURL useType default to 255
[6:39pm] spyhunter99: and URL default to 4096 (probably not an issue)
[6:39pm] KurtStam: yeah we need URL to be large..
[6:40pm] spyhunter99: Email use type default to 255, email address default to
4096
[6:40pm] spyhunter99: InstanceDetailsDescr description 1024>255
[6:41pm] spyhunter99: InstanceDetailsDocDescr desc 1024>255
[6:41pm] spyhunter99: KeyedReference keyname and value, default to 255
[6:42pm] spyhunter99: Tmodel name default > 255
[6:42pm] spyhunter99: TmodelDescr name 1024>255
[6:43pm] spyhunter99: TmodelIdentifier defaults to 255, 3 fields
[6:43pm] spyhunter99: TmodelInstanceInfoDescr description 1024>255
[6:43pm] spyhunter99: the rest are increases
> Transaction rollback when PersonName Lang is greater than 5 characters
> --
>
> Key: JUDDI-561
> URL: https://issues.apache.org/jira/browse/JUDDI-561
> Project: jUDDI
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.4
>Reporter: Alex O'Ree
>Assignee: Kurt T Stam
> Fix For: 3.1.5
>
> Attachments: validation of name lang element.patch
>
>
> Basically, there's a lack of validation of the input text for the language
> field of PersonName and possibly others that causes a rather strange soap
> fault. The following exert is from the catalina log.
> WARNING: Application
> {urn:uddi-org:v3_service}UDDIPublicationService#{urn:uddi-org:v3_service}save_business
> has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: The transaction has been rolled back. See
> the nested exceptions for details on the errors that occurred.
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:155)
> at
> org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:86)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:121)
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:60)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:75)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188)
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>
[jira] [Commented] (JUDDI-555) Add additional examples for working with UDDI
[ https://issues.apache.org/jira/browse/JUDDI-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599506#comment-13599506 ] Alex O'Ree commented on JUDDI-555: -- And copy the dependent jars to a logical directory. Or we can simply just include a batch or sh script to make it easier > Add additional examples for working with UDDI > - > > Key: JUDDI-555 > URL: https://issues.apache.org/jira/browse/JUDDI-555 > Project: jUDDI > Issue Type: Improvement > Components: feature requests >Reporter: Alex O'Ree >Assignee: Kurt T Stam >Priority: Minor > Fix For: 3.1.5 > > Attachments: SimpleBrowserPatch.patch, > simple-create-tmodel-partition.patch > > > The included coded examples only includes publishing to a registry. The most > basic (IMO) example is to simply list everything in a registry and dump it to > console. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JUDDI-555) Add additional examples for working with UDDI
[ https://issues.apache.org/jira/browse/JUDDI-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599505#comment-13599505 ] Alex O'Ree commented on JUDDI-555: -- Would it be possible to alter the maven script to include a manifest that defines the Main class and classpath attributes? This way we can simply run "java -jar simple-browser.jar and be off and running. > Add additional examples for working with UDDI > - > > Key: JUDDI-555 > URL: https://issues.apache.org/jira/browse/JUDDI-555 > Project: jUDDI > Issue Type: Improvement > Components: feature requests >Reporter: Alex O'Ree >Assignee: Kurt T Stam >Priority: Minor > Fix For: 3.1.5 > > Attachments: SimpleBrowserPatch.patch, > simple-create-tmodel-partition.patch > > > The included coded examples only includes publishing to a registry. The most > basic (IMO) example is to simply list everything in a registry and dump it to > console. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JUDDI-546) After deployed juddiv3-war-3.1.3 on WebSphere 7 default AXIS Transport URL's are not working
[ https://issues.apache.org/jira/browse/JUDDI-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599270#comment-13599270 ] Kurt T Stam commented on JUDDI-546: --- Really the only thing you'd need to do is adding services.xml and add the Axis2 dependencies: see http://axis.apache.org/axis2/java/core/docs/quickstartguide.html#deploy > After deployed juddiv3-war-3.1.3 on WebSphere 7 default AXIS Transport URL's > are not working > > > Key: JUDDI-546 > URL: https://issues.apache.org/jira/browse/JUDDI-546 > Project: jUDDI > Issue Type: Bug > Components: uddi-tck >Affects Versions: 3.1.3 >Reporter: Lokesh Nagappa >Assignee: Kurt T Stam >Priority: Critical > Fix For: 3.1.6 > > > juddiv3-war-3.1.3 on gets deployed on WebSphere 7 without any problem, but > the axis Transport URL's are not working. > javax.xml.registry.queryManagerURL=http://<>:<>/BFJUDDI/services/inquiry > javax.xml.registry.lifeCycleManagerURL=http://<>:<>/BFJUDDI/services/publish > javax.xml.registry.securityManagerURL=http://<>:<>/BFJUDDI/services/security -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (JUDDI-563) Package a Jboss 5/6 compatible war
[ https://issues.apache.org/jira/browse/JUDDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kurt T Stam closed JUDDI-563. - Resolution: Fixed Done. I used maven profile; I'm trying to stay with one build tool :). See the readme in the juddiv3.war module > Package a Jboss 5/6 compatible war > -- > > Key: JUDDI-563 > URL: https://issues.apache.org/jira/browse/JUDDI-563 > Project: jUDDI > Issue Type: New Feature > Components: core >Reporter: Alex O'Ree >Assignee: Kurt T Stam > Fix For: 3.1.5 > > > Lets build a jboss compatible war file that's integrated into the build > process, shouldn't be too hard -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
buildbot success in ASF Buildbot on juddi-trunk-openjpa
The Buildbot has detected a restored build on builder juddi-trunk-openjpa while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/juddi-trunk-openjpa/builds/289 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: ceres_ubuntu Build Reason: forced: by IRC user on channel #juddi: ping Build Source Stamp: HEAD Blamelist: Build succeeded! sincerely, -The Buildbot
buildbot failure in ASF Buildbot on juddi-trunk-openjpa
The Buildbot has detected a new failure on builder juddi-trunk-openjpa while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/juddi-trunk-openjpa/builds/288 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: ceres_ubuntu Build Reason: scheduler Build Source Stamp: [branch juddi/trunk] 1455278 Blamelist: kstam BUILD FAILED: failed compile sincerely, -The Buildbot
Warning for when you update the juddi-core(-openjpa) Unit tests
Hi guys, I just went to a bit of a build refactor to simplify our build and I was able to remove most of the hibernate/openjpa profile code. The current build now: - juddi-core builds a jar which depends on Hibernate, I moved the tests from the juddi-core-openjpa module back into this module. This way you can simply right-click 'Run As Debug' on the tests again without having to worry about JPA enhancement - juddi-core-openjpa builds a jar which depends on OpenJPA. It enhances the juddi-core.jar and it copies in the unittests from juddi-core and runs those again against this configuration. - juddiv3-war, by default it builds with CXF & OpenJPA, but it also contains profiles for CXF & Hibernate, Hibernate & JBossWS-native and Hibernate a JBossWS-cxf. The first two run on tomcat, the latter two run on jboss-6.x). - the juddiv3-war module is now also shipped in the distro, so users can build wars for other platforms. Anyway, Alex be careful updating if you modified tests in the juddi-core-openjpa module as they are now moved. Cheers, --Kurt
buildbot success in ASF Buildbot on juddi-trunk-openjpa
The Buildbot has detected a restored build on builder juddi-trunk-openjpa while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/juddi-trunk-openjpa/builds/286 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: ceres_ubuntu Build Reason: scheduler Build Source Stamp: [branch juddi/trunk] 1455262 Blamelist: kstam Build succeeded! sincerely, -The Buildbot
buildbot success in ASF Buildbot on juddi-trunk-hibernate
The Buildbot has detected a restored build on builder juddi-trunk-hibernate while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/juddi-trunk-hibernate/builds/371 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: ceres_ubuntu Build Reason: scheduler Build Source Stamp: [branch juddi/trunk] 1455262 Blamelist: kstam Build succeeded! sincerely, -The Buildbot
buildbot failure in ASF Buildbot on juddi-trunk-hibernate
The Buildbot has detected a new failure on builder juddi-trunk-hibernate while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/juddi-trunk-hibernate/builds/369 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: ceres_ubuntu Build Reason: scheduler Build Source Stamp: [branch juddi/trunk] 1455244 Blamelist: kstam BUILD FAILED: failed compile sincerely, -The Buildbot
buildbot success in ASF Buildbot on juddi-trunk-hibernate
The Buildbot has detected a restored build on builder juddi-trunk-hibernate while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/juddi-trunk-hibernate/builds/367 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: ceres_ubuntu Build Reason: scheduler Build Source Stamp: [branch juddi/trunk] 1455206 Blamelist: kstam Build succeeded! sincerely, -The Buildbot
buildbot failure in ASF Buildbot on juddi-trunk-openjpa
The Buildbot has detected a new failure on builder juddi-trunk-openjpa while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/juddi-trunk-openjpa/builds/283 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: ceres_ubuntu Build Reason: scheduler Build Source Stamp: [branch juddi/trunk] 1455185 Blamelist: kstam BUILD FAILED: failed compile sincerely, -The Buildbot
buildbot failure in ASF Buildbot on juddi-trunk-hibernate
The Buildbot has detected a new failure on builder juddi-trunk-hibernate while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/juddi-trunk-hibernate/builds/366 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: ceres_ubuntu Build Reason: scheduler Build Source Stamp: [branch juddi/trunk] 1455185 Blamelist: kstam BUILD FAILED: failed compile sincerely, -The Buildbot
[jira] [Commented] (JUDDI-567) Port the client library to .NET
[ https://issues.apache.org/jira/browse/JUDDI-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13598779#comment-13598779 ] Kurt T Stam commented on JUDDI-567: --- The WSDLS and XSDS are from the OASIS spec, so we can't change them if we want to be spec compliant. I think there were MS people on the spec committee so it's weird they would cause issues. Anyway if you *really* need to change them, then we only update the ones used to create the .NET client. > Port the client library to .NET > --- > > Key: JUDDI-567 > URL: https://issues.apache.org/jira/browse/JUDDI-567 > Project: jUDDI > Issue Type: Wish >Reporter: Alex O'Ree >Assignee: Kurt T Stam >Priority: Minor > > wouldn't it be nice if we had a similar client library for .NET based web > services for automatic registration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JUDDI-563) Package a Jboss 5/6 compatible war
[ https://issues.apache.org/jira/browse/JUDDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13598740#comment-13598740 ] Alex O'Ree commented on JUDDI-563: -- Sounds similar to the way Jboss Web services is shipped. An Ant script that selectively copies or deletes file based on the deployment target. That would do it > Package a Jboss 5/6 compatible war > -- > > Key: JUDDI-563 > URL: https://issues.apache.org/jira/browse/JUDDI-563 > Project: jUDDI > Issue Type: New Feature > Components: core >Reporter: Alex O'Ree >Assignee: Kurt T Stam > Fix For: 3.1.5 > > > Lets build a jboss compatible war file that's integrated into the build > process, shouldn't be too hard -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JUDDI-564) Advanced Browser Example
[ https://issues.apache.org/jira/browse/JUDDI-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-564: - Description: Create a new sample application and incorporates a more advanced example of performing an inquiry to a uddi registry that will give provide options for authentication and a "find_endpoints" function given a service name or key that returns all matching endpoints. The trip to finding endpoints is the useType field of access points. There are four build in options as well as user defined. Binding template (reference another binding), hosting redirectors (reference another uddi registry), wsdlDeployment (fetch the wsdl and parse the endpoints), as well as the basic "endPoint" value. Not all registries utilize the field and not all registries only post actual endPoints. (was: Create a new sample application and incorporates a more advanced example of performing an inquiry to a uddi registry that will give provide options for authentication and a "find_endpoints" given a service name or key that returns all matching endpoints, including access point useType resolution (another binding template, hosting redirections, wsdl fetch and grab the endpoints, etc).) > Advanced Browser Example > > > Key: JUDDI-564 > URL: https://issues.apache.org/jira/browse/JUDDI-564 > Project: jUDDI > Issue Type: New Feature >Reporter: Alex O'Ree >Assignee: Kurt T Stam > > Create a new sample application and incorporates a more advanced example of > performing an inquiry to a uddi registry that will give provide options for > authentication and a "find_endpoints" function given a service name or key > that returns all matching endpoints. The trip to finding endpoints is the > useType field of access points. There are four build in options as well as > user defined. Binding template (reference another binding), hosting > redirectors (reference another uddi registry), wsdlDeployment (fetch the wsdl > and parse the endpoints), as well as the basic "endPoint" value. Not all > registries utilize the field and not all registries only post actual > endPoints. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JUDDI-564) Advanced Browser Example
[ https://issues.apache.org/jira/browse/JUDDI-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-564: - Summary: Advanced Browser Example (was: Advance Browser Example) > Advanced Browser Example > > > Key: JUDDI-564 > URL: https://issues.apache.org/jira/browse/JUDDI-564 > Project: jUDDI > Issue Type: New Feature >Reporter: Alex O'Ree >Assignee: Kurt T Stam > > Create a new sample application and incorporates a more advanced example of > performing an inquiry to a uddi registry that will give provide options for > authentication and a "find_endpoints" given a service name or key that > returns all matching endpoints, including access point useType resolution > (another binding template, hosting redirections, wsdl fetch and grab the > endpoints, etc). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JUDDI-567) Port the client library to .NET
[ https://issues.apache.org/jira/browse/JUDDI-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13598725#comment-13598725 ] Alex O'Ree commented on JUDDI-567: -- Well I decided to give it a go and already and into an issue. The wsdl's and xsd's provided with juddi are not importable from niether .NET's svcutil or wsdl tools. I know I've done it before in the past, but at the least, there will have to be some changes to the schema and wsdl files. This may have unforeseen consequences with the java build so I'll hold off for now until there's more time available, or if someone asks for it > Port the client library to .NET > --- > > Key: JUDDI-567 > URL: https://issues.apache.org/jira/browse/JUDDI-567 > Project: jUDDI > Issue Type: Wish >Reporter: Alex O'Ree >Assignee: Kurt T Stam >Priority: Minor > > wouldn't it be nice if we had a similar client library for .NET based web > services for automatic registration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
