[jira] [Commented] (JUDDI-1024) Hibernate build is no longer working on CI
[ https://issues.apache.org/jira/browse/JUDDI-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553008#comment-17553008 ] Alex O'Ree commented on JUDDI-1024: --- i've still not sure how long this was broken. I've tried from v4 and up of hibernate, all with various different error conditions. Some hang forever, others barf lots of exceptions. I even rolled back to the same version we had with 3.1.4 which was 3.2.5.ga. All seem to have issues with our current code base. We can probably just drop hibernate support entirely. As long as there is at least one supported path... > Hibernate build is no longer working on CI > -- > > Key: JUDDI-1024 > URL: https://issues.apache.org/jira/browse/JUDDI-1024 > Project: jUDDI > Issue Type: Bug >Reporter: Alex O'Ree >Assignee: Kurt T Stam >Priority: Major > Attachments: juddi.log, localhost.2022-05-30.log > > > in an attempt to juddi building on github actions and get all the fancy code > scanning, dependabot stuff running, i ran into an issue with the hibernate > setup. With OpenJPA, everything is fine, however on hibernate, once the > tomcat/juddi war starts up, it throws an > java.lang.ArrayIndexOutOfBoundsException without any real context as to > what's going. > Full log output is available here: > [https://github.com/apache/juddi/runs/6479545287?check_suite_focus=true#step:6:27488] > I am unable to reproduce locally. Off of master, the command the CI job is > using is > " mvn -B install -Pgithubactiondist -Phibernate" on JDK8 > > I'll attach the logs from my system shortly -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (JUDDI-1024) Hibernate build is no longer working on CI
[ https://issues.apache.org/jira/browse/JUDDI-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1024: -- Attachment: juddi.log > Hibernate build is no longer working on CI > -- > > Key: JUDDI-1024 > URL: https://issues.apache.org/jira/browse/JUDDI-1024 > Project: jUDDI > Issue Type: Bug >Reporter: Alex O'Ree >Assignee: Kurt T Stam >Priority: Major > Attachments: juddi.log, localhost.2022-05-30.log > > > in an attempt to juddi building on github actions and get all the fancy code > scanning, dependabot stuff running, i ran into an issue with the hibernate > setup. With OpenJPA, everything is fine, however on hibernate, once the > tomcat/juddi war starts up, it throws an > java.lang.ArrayIndexOutOfBoundsException without any real context as to > what's going. > Full log output is available here: > [https://github.com/apache/juddi/runs/6479545287?check_suite_focus=true#step:6:27488] > I am unable to reproduce locally. Off of master, the command the CI job is > using is > " mvn -B install -Pgithubactiondist -Phibernate" on JDK8 > > I'll attach the logs from my system shortly -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (JUDDI-1024) Hibernate build is no longer working on CI
[ https://issues.apache.org/jira/browse/JUDDI-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1024: -- Attachment: localhost.2022-05-30.log > Hibernate build is no longer working on CI > -- > > Key: JUDDI-1024 > URL: https://issues.apache.org/jira/browse/JUDDI-1024 > Project: jUDDI > Issue Type: Bug >Reporter: Alex O'Ree >Assignee: Kurt T Stam >Priority: Major > Attachments: juddi.log, localhost.2022-05-30.log > > > in an attempt to juddi building on github actions and get all the fancy code > scanning, dependabot stuff running, i ran into an issue with the hibernate > setup. With OpenJPA, everything is fine, however on hibernate, once the > tomcat/juddi war starts up, it throws an > java.lang.ArrayIndexOutOfBoundsException without any real context as to > what's going. > Full log output is available here: > [https://github.com/apache/juddi/runs/6479545287?check_suite_focus=true#step:6:27488] > I am unable to reproduce locally. Off of master, the command the CI job is > using is > " mvn -B install -Pgithubactiondist -Phibernate" on JDK8 > > I'll attach the logs from my system shortly -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (JUDDI-1024) Hibernate build is no longer working on CI
Alex O'Ree created JUDDI-1024: - Summary: Hibernate build is no longer working on CI Key: JUDDI-1024 URL: https://issues.apache.org/jira/browse/JUDDI-1024 Project: jUDDI Issue Type: Bug Reporter: Alex O'Ree Assignee: Kurt T Stam Attachments: juddi.log, localhost.2022-05-30.log in an attempt to juddi building on github actions and get all the fancy code scanning, dependabot stuff running, i ran into an issue with the hibernate setup. With OpenJPA, everything is fine, however on hibernate, once the tomcat/juddi war starts up, it throws an java.lang.ArrayIndexOutOfBoundsException without any real context as to what's going. Full log output is available here: [https://github.com/apache/juddi/runs/6479545287?check_suite_focus=true#step:6:27488] I am unable to reproduce locally. Off of master, the command the CI job is using is " mvn -B install -Pgithubactiondist -Phibernate" on JDK8 I'll attach the logs from my system shortly -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (JUDDI-1023) upgrade log4j or select another logging library
Alex O'Ree created JUDDI-1023: - Summary: upgrade log4j or select another logging library Key: JUDDI-1023 URL: https://issues.apache.org/jira/browse/JUDDI-1023 Project: jUDDI Issue Type: Improvement Reporter: Alex O'Ree we're using a super old, no longer supported log4j version with known issues. update to upgrade -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JUDDI-1020) Use an alternate documentation mechanism than the jboss docbook plugin
[ https://issues.apache.org/jira/browse/JUDDI-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537206#comment-17537206 ] Alex O'Ree commented on JUDDI-1020: --- current draft outputs attached, still needs a lot of work > Use an alternate documentation mechanism than the jboss docbook plugin > -- > > Key: JUDDI-1020 > URL: https://issues.apache.org/jira/browse/JUDDI-1020 > Project: jUDDI > Issue Type: Improvement > Components: build >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > Attachments: juddi-client-guide.pdf, juddi-server-guide.pdf > > > long story short, maven frequently has issues resolving either xlts or the > docbook plugins. I think it's an issue on the jboss maven repo either > blocking too many concurrent requests or some kind of quote or bandwidth cap, > etc. Maybe we can use the maven site plugin + pdf plugins to get a near > equivalent setup or maybe there are some other alternatives out there -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (JUDDI-1020) Use an alternate documentation mechanism than the jboss docbook plugin
[ https://issues.apache.org/jira/browse/JUDDI-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1020: -- Attachment: juddi-server-guide.pdf juddi-client-guide.pdf > Use an alternate documentation mechanism than the jboss docbook plugin > -- > > Key: JUDDI-1020 > URL: https://issues.apache.org/jira/browse/JUDDI-1020 > Project: jUDDI > Issue Type: Improvement > Components: build >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > Attachments: juddi-client-guide.pdf, juddi-server-guide.pdf > > > long story short, maven frequently has issues resolving either xlts or the > docbook plugins. I think it's an issue on the jboss maven repo either > blocking too many concurrent requests or some kind of quote or bandwidth cap, > etc. Maybe we can use the maven site plugin + pdf plugins to get a near > equivalent setup or maybe there are some other alternatives out there -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (JUDDI-1020) Use an alternate documentation mechanism than the jboss docbook plugin
[ https://issues.apache.org/jira/browse/JUDDI-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree reassigned JUDDI-1020: - Assignee: Alex O'Ree > Use an alternate documentation mechanism than the jboss docbook plugin > -- > > Key: JUDDI-1020 > URL: https://issues.apache.org/jira/browse/JUDDI-1020 > Project: jUDDI > Issue Type: Improvement > Components: build >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > > long story short, maven frequently has issues resolving either xlts or the > docbook plugins. I think it's an issue on the jboss maven repo either > blocking too many concurrent requests or some kind of quote or bandwidth cap, > etc. Maybe we can use the maven site plugin + pdf plugins to get a near > equivalent setup or maybe there are some other alternatives out there -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (JUDDI-1022) Address codeql warnings
Alex O'Ree created JUDDI-1022: - Summary: Address codeql warnings Key: JUDDI-1022 URL: https://issues.apache.org/jira/browse/JUDDI-1022 Project: jUDDI Issue Type: Improvement Reporter: Alex O'Ree i finally got codeql up and running at github. it found a few things that should be addressed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work stopped] (JUDDI-651) Create unit tests for juddi-gui functions
[ https://issues.apache.org/jira/browse/JUDDI-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JUDDI-651 stopped by Alex O'Ree. > Create unit tests for juddi-gui functions > - > > Key: JUDDI-651 > URL: https://issues.apache.org/jira/browse/JUDDI-651 > Project: jUDDI > Issue Type: Improvement > Components: juddi-gui >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > Fix For: FUTURE > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (JUDDI-1005) Need To have correct options to upgrade JUDDI DB Schema
[
https://issues.apache.org/jira/browse/JUDDI-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree resolved JUDDI-1005.
---
Resolution: Fixed
> Need To have correct options to upgrade JUDDI DB Schema
> ---
>
> Key: JUDDI-1005
> URL: https://issues.apache.org/jira/browse/JUDDI-1005
> Project: jUDDI
> Issue Type: Bug
> Components: juddi-tomcat
>Affects Versions: 3.3.6, 3.3.7
>Reporter: Amol Bhonsle
>Priority: Major
> Fix For: 3.3.7
>
> Attachments:
> uddi-migration-tool-3.3.8-SNAPSHOT-jar-with-dependencies.jar
>
>
> We are trying to update JUDDI DB from JUDDI-3.0.4 to JUDDI-3.3.7. JUDDI DB is
> hosted on SQL Server. We use openjpa-2.3.0 which is provided by juddi-3.3.7
> distribution.
>
> As per openjpa-2.3.0 documentation:
> {{drop option of SchemaTool should do following:}}
> {{drop}}: Drop all schema components in the schema XML. Tables will only be
> dropped if they would have 0 columns after dropping all columns listed in the
> XML.
> and add option should do following:
> {{add}}: This is the default action if you do not specify one. It brings the
> schema up-to-date with the given XML document by adding tables, columns,
> indexes, etc. This action never drops any schema components.
> Also it is allowed in persistence.xml to use options as comma separated, so
> we tried following option in persistence.xml to drop old tables and create
> new tables as per juddi-3.3.7 schema but it did not work:
> value="buildSchema(SchemaAction='drop,add')"/>
>
> This gives following Exception when JUDDI is deployed by tomcat :
>
> {code:java}
> SEVERE: Exception sending context initialized event to listener instance of
> class org.springframework.web.context.ContextLoaderListenerSEVERE: Exception
> sending context initialized event to listener instance of class
> org.springframework.web.context.ContextLoaderListenerorg.springframework.beans.factory.BeanCreationException:
> Error creating bean with name 'inquiry': Cannot create inner bean '(inner
> bean)#fa6535a' of type [org.apache.juddi.api.impl.UDDIInquiryImpl] while
> setting constructor argument; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name '(inner bean)#fa6535a': Instantiation of bean failed; nested
> exception is org.springframework.beans.BeanInstantiationException: Failed to
> instantiate [org.apache.juddi.api.impl.UDDIInquiryImpl]: Constructor threw
> exception; nested exception is general error> org.apache.openjpa.persistence.PersistenceException: The
> object 'PK__j3_clerk__5609ADDDCF01D08E' is dependent on column 'clerk_name'.
> \{stmnt 1807668378 ALTER TABLE j3_clerk DROP COLUMN clerk_name} [code=5074,
> state=S0001] at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:389)
> at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:134)
> at
> org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:691)
> at
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:196)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1358)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1204)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:557)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$208/1654431226.getObject(Unknown
> Source) at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:879)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:878)
> at
>
[jira] [Updated] (JUDDI-1005) Need To have correct options to upgrade JUDDI DB Schema
[
https://issues.apache.org/jira/browse/JUDDI-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree updated JUDDI-1005:
--
Fix Version/s: 3.3.7
> Need To have correct options to upgrade JUDDI DB Schema
> ---
>
> Key: JUDDI-1005
> URL: https://issues.apache.org/jira/browse/JUDDI-1005
> Project: jUDDI
> Issue Type: Bug
> Components: juddi-tomcat
>Affects Versions: 3.3.6, 3.3.7
>Reporter: Amol Bhonsle
>Priority: Major
> Fix For: 3.3.7
>
> Attachments:
> uddi-migration-tool-3.3.8-SNAPSHOT-jar-with-dependencies.jar
>
>
> We are trying to update JUDDI DB from JUDDI-3.0.4 to JUDDI-3.3.7. JUDDI DB is
> hosted on SQL Server. We use openjpa-2.3.0 which is provided by juddi-3.3.7
> distribution.
>
> As per openjpa-2.3.0 documentation:
> {{drop option of SchemaTool should do following:}}
> {{drop}}: Drop all schema components in the schema XML. Tables will only be
> dropped if they would have 0 columns after dropping all columns listed in the
> XML.
> and add option should do following:
> {{add}}: This is the default action if you do not specify one. It brings the
> schema up-to-date with the given XML document by adding tables, columns,
> indexes, etc. This action never drops any schema components.
> Also it is allowed in persistence.xml to use options as comma separated, so
> we tried following option in persistence.xml to drop old tables and create
> new tables as per juddi-3.3.7 schema but it did not work:
> value="buildSchema(SchemaAction='drop,add')"/>
>
> This gives following Exception when JUDDI is deployed by tomcat :
>
> {code:java}
> SEVERE: Exception sending context initialized event to listener instance of
> class org.springframework.web.context.ContextLoaderListenerSEVERE: Exception
> sending context initialized event to listener instance of class
> org.springframework.web.context.ContextLoaderListenerorg.springframework.beans.factory.BeanCreationException:
> Error creating bean with name 'inquiry': Cannot create inner bean '(inner
> bean)#fa6535a' of type [org.apache.juddi.api.impl.UDDIInquiryImpl] while
> setting constructor argument; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name '(inner bean)#fa6535a': Instantiation of bean failed; nested
> exception is org.springframework.beans.BeanInstantiationException: Failed to
> instantiate [org.apache.juddi.api.impl.UDDIInquiryImpl]: Constructor threw
> exception; nested exception is general error> org.apache.openjpa.persistence.PersistenceException: The
> object 'PK__j3_clerk__5609ADDDCF01D08E' is dependent on column 'clerk_name'.
> \{stmnt 1807668378 ALTER TABLE j3_clerk DROP COLUMN clerk_name} [code=5074,
> state=S0001] at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:389)
> at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:134)
> at
> org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:691)
> at
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:196)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1358)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1204)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:557)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$208/1654431226.getObject(Unknown
> Source) at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:879)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:878)
> at
>
[jira] [Resolved] (JUDDI-1021) Remove the digital signature applet
[ https://issues.apache.org/jira/browse/JUDDI-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1021. --- Resolution: Fixed > Remove the digital signature applet > --- > > Key: JUDDI-1021 > URL: https://issues.apache.org/jira/browse/JUDDI-1021 > Project: jUDDI > Issue Type: Improvement >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > > looks like this was removed in jdk8 at some point (it is no longer available > in 1.8.302 on ubuntu, plugin.jar is missing entirely even with icedtea > installed). It's currently deprecated and marked for removal in jdk17. See > also JUDDI-990 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work started] (JUDDI-1021) Remove the digital signature applet
[ https://issues.apache.org/jira/browse/JUDDI-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JUDDI-1021 started by Alex O'Ree. - > Remove the digital signature applet > --- > > Key: JUDDI-1021 > URL: https://issues.apache.org/jira/browse/JUDDI-1021 > Project: jUDDI > Issue Type: Improvement >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > > looks like this was removed in jdk8 at some point (it is no longer available > in 1.8.302 on ubuntu, plugin.jar is missing entirely even with icedtea > installed). It's currently deprecated and marked for removal in jdk17. See > also JUDDI-990 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (JUDDI-1021) Remove the digital signature applet
[ https://issues.apache.org/jira/browse/JUDDI-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree reassigned JUDDI-1021: - Assignee: Alex O'Ree > Remove the digital signature applet > --- > > Key: JUDDI-1021 > URL: https://issues.apache.org/jira/browse/JUDDI-1021 > Project: jUDDI > Issue Type: Improvement >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > > looks like this was removed in jdk8 at some point (it is no longer available > in 1.8.302 on ubuntu, plugin.jar is missing entirely even with icedtea > installed). It's currently deprecated and marked for removal in jdk17. See > also JUDDI-990 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (JUDDI-1021) Remove the digital signature applet
Alex O'Ree created JUDDI-1021: - Summary: Remove the digital signature applet Key: JUDDI-1021 URL: https://issues.apache.org/jira/browse/JUDDI-1021 Project: jUDDI Issue Type: Improvement Reporter: Alex O'Ree looks like this was removed in jdk8 at some point (it is no longer available in 1.8.302 on ubuntu, plugin.jar is missing entirely even with icedtea installed). It's currently deprecated and marked for removal in jdk17. See also JUDDI-990 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (JUDDI-1020) Use an alternate documentation mechanism than the jboss docbook plugin
Alex O'Ree created JUDDI-1020: - Summary: Use an alternate documentation mechanism than the jboss docbook plugin Key: JUDDI-1020 URL: https://issues.apache.org/jira/browse/JUDDI-1020 Project: jUDDI Issue Type: Improvement Components: build Reporter: Alex O'Ree long story short, maven frequently has issues resolving either xlts or the docbook plugins. I think it's an issue on the jboss maven repo either blocking too many concurrent requests or some kind of quote or bandwidth cap, etc. Maybe we can use the maven site plugin + pdf plugins to get a near equivalent setup or maybe there are some other alternatives out there -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JUDDI-990) Find a better solution for in browser digital signatures than a java applet
[ https://issues.apache.org/jira/browse/JUDDI-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523353#comment-17523353 ] Alex O'Ree commented on JUDDI-990: -- [https://github.com/PeculiarVentures/xadesjs] this seems like a potential solution > Find a better solution for in browser digital signatures than a java applet > --- > > Key: JUDDI-990 > URL: https://issues.apache.org/jira/browse/JUDDI-990 > Project: jUDDI > Issue Type: Improvement > Components: juddi-gui >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > > this might work... > https://github.com/PeculiarVentures/xadesjs -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work started] (JUDDI-1019) Support newer java runtimes
[ https://issues.apache.org/jira/browse/JUDDI-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JUDDI-1019 started by Alex O'Ree. - > Support newer java runtimes > --- > > Key: JUDDI-1019 > URL: https://issues.apache.org/jira/browse/JUDDI-1019 > Project: jUDDI > Issue Type: Improvement > Components: build >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > > probably past due, but we should support > java 8 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (JUDDI-1019) Support newer java runtimes
[ https://issues.apache.org/jira/browse/JUDDI-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree reassigned JUDDI-1019: - Assignee: Alex O'Ree > Support newer java runtimes > --- > > Key: JUDDI-1019 > URL: https://issues.apache.org/jira/browse/JUDDI-1019 > Project: jUDDI > Issue Type: Improvement > Components: build >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > > probably past due, but we should support > java 8 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (JUDDI-1019) Support newer java runtimes
Alex O'Ree created JUDDI-1019: - Summary: Support newer java runtimes Key: JUDDI-1019 URL: https://issues.apache.org/jira/browse/JUDDI-1019 Project: jUDDI Issue Type: Improvement Components: build Reporter: Alex O'Ree probably past due, but we should support > java 8 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JUDDI-1018) CVE-2021-37578 Apache jUDDI Remote code execution
[ https://issues.apache.org/jira/browse/JUDDI-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17389104#comment-17389104 ] Alex O'Ree commented on JUDDI-1018: --- addressed via [https://github.com/apache/juddi/commit/e6ae0f4ce39e73ba29ab1c2926a41ac71e68574a] > CVE-2021-37578 Apache jUDDI Remote code execution > - > > Key: JUDDI-1018 > URL: https://issues.apache.org/jira/browse/JUDDI-1018 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.10 > > > Details will be populated +30 days after release > > REFERENCES: [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37578] > [https://juddi.apache.org/security.html] > > DESCRIPTION: > Apache jUDDI uses several classes related to Java's Remote Method Invocation > (RMI) which (as an extension to UDDI) provides an alternate transport for > accessing UDDI services. > RMI uses the default Java serialization mechanism to pass parameters in RMI > invocations. A remote attacker can send a malicious serialized object to the > above RMI entries. The objects get deserialized without any check on the > incoming data. In the worst case, it may let the attacker run arbitrary code > remotely. > For both jUDDI web service applications and jUDDI clients, the usage of RMI > is disabled by default. Since this is an optional feature and an extension to > the UDDI protocol, the likelihood of impact is low. Starting with 3.3.10, all > RMI related code was removed. > Mitigation: > jUDDI Clients, disable RMITransports (found in uddi.xml) and use alternate > transports such as HTTPS. > jUDDI Server (juddiv3.war/WEB-INF/classes/juddiv3.xml), disable JNDI and RMI > settings in juddiv3.xml. > The appropriate settings are located below in xpath style notation. > juddi/jndi/registration=false > juddi/rmi/registration=false > > If the settings are not present, then JNDI and RMI are already disabled. This > is the default setting. > > > Reported by Artem Smotrakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1018) CVE-2021-37578 Apache jUDDI Remote code execution
[ https://issues.apache.org/jira/browse/JUDDI-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1018: -- Description: Details will be populated +30 days after release REFERENCES: [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37578] [https://juddi.apache.org/security.html] DESCRIPTION: Apache jUDDI uses several classes related to Java's Remote Method Invocation (RMI) which (as an extension to UDDI) provides an alternate transport for accessing UDDI services. RMI uses the default Java serialization mechanism to pass parameters in RMI invocations. A remote attacker can send a malicious serialized object to the above RMI entries. The objects get deserialized without any check on the incoming data. In the worst case, it may let the attacker run arbitrary code remotely. For both jUDDI web service applications and jUDDI clients, the usage of RMI is disabled by default. Since this is an optional feature and an extension to the UDDI protocol, the likelihood of impact is low. Starting with 3.3.10, all RMI related code was removed. Mitigation: jUDDI Clients, disable RMITransports (found in uddi.xml) and use alternate transports such as HTTPS. jUDDI Server (juddiv3.war/WEB-INF/classes/juddiv3.xml), disable JNDI and RMI settings in juddiv3.xml. The appropriate settings are located below in xpath style notation. juddi/jndi/registration=false juddi/rmi/registration=false If the settings are not present, then JNDI and RMI are already disabled. This is the default setting. Reported by Artem Smotrakov was:Details will be populated +30 days after release > CVE-2021-37578 Apache jUDDI Remote code execution > - > > Key: JUDDI-1018 > URL: https://issues.apache.org/jira/browse/JUDDI-1018 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.10 > > > Details will be populated +30 days after release > > REFERENCES: [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37578] > [https://juddi.apache.org/security.html] > > DESCRIPTION: > Apache jUDDI uses several classes related to Java's Remote Method Invocation > (RMI) which (as an extension to UDDI) provides an alternate transport for > accessing UDDI services. > RMI uses the default Java serialization mechanism to pass parameters in RMI > invocations. A remote attacker can send a malicious serialized object to the > above RMI entries. The objects get deserialized without any check on the > incoming data. In the worst case, it may let the attacker run arbitrary code > remotely. > For both jUDDI web service applications and jUDDI clients, the usage of RMI > is disabled by default. Since this is an optional feature and an extension to > the UDDI protocol, the likelihood of impact is low. Starting with 3.3.10, all > RMI related code was removed. > Mitigation: > jUDDI Clients, disable RMITransports (found in uddi.xml) and use alternate > transports such as HTTPS. > jUDDI Server (juddiv3.war/WEB-INF/classes/juddiv3.xml), disable JNDI and RMI > settings in juddiv3.xml. > The appropriate settings are located below in xpath style notation. > juddi/jndi/registration=false > juddi/rmi/registration=false > > If the settings are not present, then JNDI and RMI are already disabled. This > is the default setting. > > > Reported by Artem Smotrakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JUDDI-1018) CVE-2021-37578 Apache jUDDI Remote code execution
[ https://issues.apache.org/jira/browse/JUDDI-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree closed JUDDI-1018. - > CVE-2021-37578 Apache jUDDI Remote code execution > - > > Key: JUDDI-1018 > URL: https://issues.apache.org/jira/browse/JUDDI-1018 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.10 > > > Details will be populated +30 days after release > > REFERENCES: [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37578] > [https://juddi.apache.org/security.html] > > DESCRIPTION: > Apache jUDDI uses several classes related to Java's Remote Method Invocation > (RMI) which (as an extension to UDDI) provides an alternate transport for > accessing UDDI services. > RMI uses the default Java serialization mechanism to pass parameters in RMI > invocations. A remote attacker can send a malicious serialized object to the > above RMI entries. The objects get deserialized without any check on the > incoming data. In the worst case, it may let the attacker run arbitrary code > remotely. > For both jUDDI web service applications and jUDDI clients, the usage of RMI > is disabled by default. Since this is an optional feature and an extension to > the UDDI protocol, the likelihood of impact is low. Starting with 3.3.10, all > RMI related code was removed. > Mitigation: > jUDDI Clients, disable RMITransports (found in uddi.xml) and use alternate > transports such as HTTPS. > jUDDI Server (juddiv3.war/WEB-INF/classes/juddiv3.xml), disable JNDI and RMI > settings in juddiv3.xml. > The appropriate settings are located below in xpath style notation. > juddi/jndi/registration=false > juddi/rmi/registration=false > > If the settings are not present, then JNDI and RMI are already disabled. This > is the default setting. > > > Reported by Artem Smotrakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1018) CVE-2021-37578 Apache jUDDI Remote code execution
[ https://issues.apache.org/jira/browse/JUDDI-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1018: -- Summary: CVE-2021-37578 Apache jUDDI Remote code execution (was: TBD) > CVE-2021-37578 Apache jUDDI Remote code execution > - > > Key: JUDDI-1018 > URL: https://issues.apache.org/jira/browse/JUDDI-1018 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.10 > > > Details will be populated +30 days after release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1018) TBD
[ https://issues.apache.org/jira/browse/JUDDI-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1018. --- Resolution: Fixed > TBD > --- > > Key: JUDDI-1018 > URL: https://issues.apache.org/jira/browse/JUDDI-1018 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.10 > > > Details will be populated +30 days after release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1018) TBD
[ https://issues.apache.org/jira/browse/JUDDI-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1018: -- Fix Version/s: 3.3.10 > TBD > --- > > Key: JUDDI-1018 > URL: https://issues.apache.org/jira/browse/JUDDI-1018 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.10 > > > Details will be populated +30 days after release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1018) TBD
[ https://issues.apache.org/jira/browse/JUDDI-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1018: -- Summary: TBD (was: Unspecified security issue) > TBD > --- > > Key: JUDDI-1018 > URL: https://issues.apache.org/jira/browse/JUDDI-1018 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > > Details will be populated +30 days after release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JUDDI-1018) Unspecified security issue
Alex O'Ree created JUDDI-1018: - Summary: Unspecified security issue Key: JUDDI-1018 URL: https://issues.apache.org/jira/browse/JUDDI-1018 Project: jUDDI Issue Type: Bug Components: core Reporter: Alex O'Ree Assignee: Alex O'Ree Details will be populated +30 days after release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JUDDI-1004) JUDDI-3.3.7 With SQL Server Database Gives Primary Key Violation For Table j3_category_bag
[
https://issues.apache.org/jira/browse/JUDDI-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree closed JUDDI-1004.
-
> JUDDI-3.3.7 With SQL Server Database Gives Primary Key Violation For Table
> j3_category_bag
> ---
>
> Key: JUDDI-1004
> URL: https://issues.apache.org/jira/browse/JUDDI-1004
> Project: jUDDI
> Issue Type: Bug
> Components: core, juddi-tomcat
>Affects Versions: 3.3.7
>Reporter: Amol Bhonsle
>Priority: Major
> Labels: jUDDI, juddi
> Fix For: 3.3.9
>
>
> Our application is based on JUDDI-3.3.7 When we try to publishService() we
> get following Exception:
>
>
> Caused by:
> org.apache.openjpa.persistence.RollbackException: The transaction has been
> rolled back. See the nested exceptions for details on the errors that
> occurred.
> FailedObject:
> [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7]
> at
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:594)
> at
> org.apache.juddi.api.impl.UDDIPublicationImpl.saveService(UDDIPublicationImpl.java:892)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179)
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.performInvocation(JAXWSMethodInvoker.java:66)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
> ... 42 more
> Caused by:
> org.apache.openjpa.persistence.PersistenceException: The transaction has been
> rolled back. See the nested exceptions for details on the errors that
> occurred.
> FailedObject:
> [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7]
> at
> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2370)
> at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2207)
> at
> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2105)
> at
> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:2023)
> at
> org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
> at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1528)
> at
> org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:933)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:570)
> ... 50 more
> Caused by:
> org.apache.openjpa.persistence.EntityExistsException: Violation of PRIMARY
> KEY constraint 'PK__j3_categ__3213E83FD3C84046'. Cannot insert duplicate key
> in object 'dbo.j3_category_bag'. The duplicate key value is (902). {prepstmnt
> 1928491676 INSERT INTO j3_category_bag (id) VALUES (?)} [code=2627,
> state=23000]
> FailedObject:
> [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7]
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4959)
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4934)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:134)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:76)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:144)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:100)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:88)
> at
> org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:203)
> at
> org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:89)
> at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:104)
> at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:77)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:732)
> at
>
[jira] [Closed] (JUDDI-1010) save_business does not properly save the accessPoint URLType when using the v2 Publish API
[ https://issues.apache.org/jira/browse/JUDDI-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree closed JUDDI-1010. - > save_business does not properly save the accessPoint URLType when using the > v2 Publish API > -- > > Key: JUDDI-1010 > URL: https://issues.apache.org/jira/browse/JUDDI-1010 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > The v2 Publish API – save_business does not save the values passed in for the > accessPoint URLType in the database, endpoint is always put in the DB. The > response from the v2 call includes the proper values for the accessPoint > URLType. The v3 call saves the accessPoint URLType properly. Note the value > for the authtoken was changed in the example XML. > > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > authtoken:ZZZ > > Test Provider > > > Test Service > > > URLType="http">http://somedomain.com/testservice.svc > > tModelKey="uuid:ee846ebf-ef30-4e73-8558-0eba166d002a" /> > > > > URLType="mailto">mailto:t...@domain.com > > tModelKey="uuid:f05b5947-8831-4c6a-9aa3-009ce5e6a707" /> > > > > > > > tModelKey="uuid:578a72bd-8f35-4099-b559-8b4997389bc5" keyName="DUNS" > keyValue="12-345-6781" /> > > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > operator="uddi:juddi.apache.org:node1" truncated="false"> > operator="uddi:juddi.apache.org:node1"> > Test Provider > > serviceKey="uddi:juddi.apache.org:99a4c6f6-c7f9-4536-a810-73c60f605a97"> > Test Service > > bindingKey="uddi:juddi.apache.org:2c3da830-751a-4304-8da4-006dd0d0007e"> > URLType="http">http://somedomain.com/testservice.svc > > tModelKey="uuid:ee846ebf-ef30-4e73-8558-0eba166d002a"/> > > > bindingKey="uddi:juddi.apache.org:c859a269-fefb-4f32-9047-e3de41b36900"> > URLType="mailto">mailto:t...@domain.com > > tModelKey="uuid:f05b5947-8831-4c6a-9aa3-009ce5e6a707"/> > > > > > > > tModelKey="uuid:578a72bd-8f35-4099-b559-8b4997389bc5" keyName="DUNS" > keyValue="12-345-6781"/> > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JUDDI-1012) MS SQL Server Sequence table change
[ https://issues.apache.org/jira/browse/JUDDI-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree closed JUDDI-1012. - > MS SQL Server Sequence table change > --- > > Key: JUDDI-1012 > URL: https://issues.apache.org/jira/browse/JUDDI-1012 > Project: jUDDI > Issue Type: Improvement > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > SQL Server 2012 is the oldest version that is supported by Microsoft. This > and newer versions support sequences. > > File mssql2000.ddl: > > create table hibernate_sequence (next_val numeric(19,0)); > Multiple instances of insert into hibernate_sequence values ( 1 ); > > Suggestion to change this to: > create sequence hibernate_sequence start with 1 increment by 1; > > To remove the sequence use: DROP sequence hibernate_sequence; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JUDDI-1006) Saving an Access Point Type
[ https://issues.apache.org/jira/browse/JUDDI-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree closed JUDDI-1006. - > Saving an Access Point Type > --- > > Key: JUDDI-1006 > URL: https://issues.apache.org/jira/browse/JUDDI-1006 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Minor > Fix For: 3.3.9 > > > Using juddi default (v3) you can create an access point type of Mailto which > saves to the database and is displayed properly in the UI. When using > juddiv2, the access point type displays as endpoint. > > Using juddiv2 create an Access Point using a random binding template key, > access point type “Mailto” and Access Point Value: > “[[t...@email.com|mailto:[t...@email.com]|mailto:t...@email.com]” and save > the access point. The value endPoint is saved in the database, not Mailto. > If the database contains a value of Mailto in the access_point_type field, it > still displays endPoint in the UI. > > Note that the response from the v2 Inquire API returns the value of mailto if > this value is in the database. > URLType="mailto">[mailto:t...@email.commailto:t...@email.com%3c/ns2:accessPoint]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JUDDI-1011) MS SQL Server table - length of field too large
[ https://issues.apache.org/jira/browse/JUDDI-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree closed JUDDI-1011. - > MS SQL Server table - length of field too large > --- > > Key: JUDDI-1011 > URL: https://issues.apache.org/jira/browse/JUDDI-1011 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > File mssql2000.ddl > > create table j3_tmodel_instance_info (id numeric(19,0) not null, > instance_parms varchar(8192), tmodel_key varchar(255) not null, entity_key > varchar(255) not null, primary key (id)); > > The instance_parms column exceeds the maximum length of a varchar field in > SQL Server of 8000 characters. I’ve reviewed the scripts for the other > database engines and the best option is to define this column as > instance_parms varchar(max). Another option is to define this column as > instance_parms varchar(8000) although if there was a good reason to make it > 8192 this value could overflow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JUDDI-1008) find_business returns an error when querying a tModel when using the v2 Inquire API
[ https://issues.apache.org/jira/browse/JUDDI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree closed JUDDI-1008. - > find_business returns an error when querying a tModel when using the v2 > Inquire API > --- > > Key: JUDDI-1008 > URL: https://issues.apache.org/jira/browse/JUDDI-1008 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > The v2 Inquire API find_business returns an error when querying for a tModel. > The v3 call gives a valid response. > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > > soap:Server > At least one search criterion must be supplied. Try using > '%' as a wild card with the a 'approximateMatch' find qualifer for > everything > > operator="uddi:juddi.apache.org:node1" truncated="false"> > > A serious technical error has > occurred while processing the request. > > > > > > > > V3 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V3 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > xmlns:ns10="urn:uddi-org:vs_v3" xmlns:ns9="urn:uddi-org:repl_v3" > xmlns:ns8="urn:uddi-org:policy_v3" xmlns:ns7="urn:uddi-org:custody_v3" > xmlns:ns6="urn:uddi-org:subr_v3" xmlns:ns5="urn:uddi-org:sub_v3" > xmlns:ns4="urn:uddi-org:vscache_v3" > xmlns:ns3="http://www.w3.org/2000/09/xmldsig#; > xmlns:ns2="urn:uddi-org:api_v3" truncated="false"> > > 1 > 1 > 1 > > > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Provider > > serviceKey="uddi:juddi.apache.org:249f327a-68bd-4cd7-b358-c0347369e573" > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Service > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JUDDI-1015) Oracle database start up issue due to max string length
[
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree closed JUDDI-1015.
-
> Oracle database start up issue due to max string length
> ---
>
> Key: JUDDI-1015
> URL: https://issues.apache.org/jira/browse/JUDDI-1015
> Project: jUDDI
> Issue Type: Bug
>Reporter: Alex O'Ree
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.9
>
>
> from the juddi mailing list
>
> {color:#172b4d}Oracle Version of Juddi Due to string limit for a column
> CREATE TABLE j3_binding_template (entity_key VARCHAR2(255) NOT NULL,
> access_point_type VARCHAR2(255), access_point_url VARCHAR2(4096),
> hosting_redirector VARCHAR2(255), service_key VARCHAR2(255) NOT NULL, PRIMARY
> KEY (entity_key)) {color}*Oracle max varchar limit: 4000*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JUDDI-1014) Binding Editor – tModel Instance Information
[ https://issues.apache.org/jira/browse/JUDDI-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree closed JUDDI-1014. - > Binding Editor – tModel Instance Information > > > Key: JUDDI-1014 > URL: https://issues.apache.org/jira/browse/JUDDI-1014 > Project: jUDDI > Issue Type: Improvement > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > Attachments: tModel Instance Info.png > > > It would be nice to display the tModel Name as you most likely will not know > what each tModel the GUID is for. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JUDDI-1013) GUI adding records
[ https://issues.apache.org/jira/browse/JUDDI-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree closed JUDDI-1013. - > GUI adding records > -- > > Key: JUDDI-1013 > URL: https://issues.apache.org/jira/browse/JUDDI-1013 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > Create a business and save it. Navigate to the Services to add a service. > You see the message “Please save the business first, then you can add > services.” You need to open the business again before you can add a service. > This behavior occurs at multiple levels as you go deeper into the business > definition. It does not seem like the page is refreshing to know that the > data has been saved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JUDDI-1009) Browse Businesses using juddiv2 page navigation issue
[ https://issues.apache.org/jira/browse/JUDDI-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree closed JUDDI-1009. - > Browse Businesses using juddiv2 page navigation issue > - > > Key: JUDDI-1009 > URL: https://issues.apache.org/jira/browse/JUDDI-1009 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > Attachments: Business List v2.png > > > Browse Businesses using the default (v3) works properly. Total records shows > 473 businesses. Paging through the records with the right arrow button > properly moves you to the next set of 20 businesses. > > Select juddiv2 as the active configuration. Browse Businesses. Total > records shows 20 businesses. Paging trough the records lets you go 1 page > forward showing an offset of 20. The records displayed are the same 20 on > the first page with offset 0. > > This issue is present for Services and tModels. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1013) GUI adding records
[ https://issues.apache.org/jira/browse/JUDDI-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1013: -- Fix Version/s: 3.3.9 > GUI adding records > -- > > Key: JUDDI-1013 > URL: https://issues.apache.org/jira/browse/JUDDI-1013 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > Create a business and save it. Navigate to the Services to add a service. > You see the message “Please save the business first, then you can add > services.” You need to open the business again before you can add a service. > This behavior occurs at multiple levels as you go deeper into the business > definition. It does not seem like the page is refreshing to know that the > data has been saved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1013) GUI adding records
[ https://issues.apache.org/jira/browse/JUDDI-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1013: -- Fix Version/s: (was: 3.3.8) > GUI adding records > -- > > Key: JUDDI-1013 > URL: https://issues.apache.org/jira/browse/JUDDI-1013 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > > Create a business and save it. Navigate to the Services to add a service. > You see the message “Please save the business first, then you can add > services.” You need to open the business again before you can add a service. > This behavior occurs at multiple levels as you go deeper into the business > definition. It does not seem like the page is refreshing to know that the > data has been saved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1004) JUDDI-3.3.7 With SQL Server Database Gives Primary Key Violation For Table j3_category_bag
[
https://issues.apache.org/jira/browse/JUDDI-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree updated JUDDI-1004:
--
Fix Version/s: (was: 3.3.8)
3.3.9
> JUDDI-3.3.7 With SQL Server Database Gives Primary Key Violation For Table
> j3_category_bag
> ---
>
> Key: JUDDI-1004
> URL: https://issues.apache.org/jira/browse/JUDDI-1004
> Project: jUDDI
> Issue Type: Bug
> Components: core, juddi-tomcat
>Affects Versions: 3.3.7
>Reporter: Amol Bhonsle
>Priority: Major
> Labels: jUDDI, juddi
> Fix For: 3.3.9
>
>
> Our application is based on JUDDI-3.3.7 When we try to publishService() we
> get following Exception:
>
>
> Caused by:
> org.apache.openjpa.persistence.RollbackException: The transaction has been
> rolled back. See the nested exceptions for details on the errors that
> occurred.
> FailedObject:
> [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7]
> at
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:594)
> at
> org.apache.juddi.api.impl.UDDIPublicationImpl.saveService(UDDIPublicationImpl.java:892)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179)
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.performInvocation(JAXWSMethodInvoker.java:66)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
> ... 42 more
> Caused by:
> org.apache.openjpa.persistence.PersistenceException: The transaction has been
> rolled back. See the nested exceptions for details on the errors that
> occurred.
> FailedObject:
> [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7]
> at
> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2370)
> at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2207)
> at
> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2105)
> at
> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:2023)
> at
> org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
> at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1528)
> at
> org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:933)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:570)
> ... 50 more
> Caused by:
> org.apache.openjpa.persistence.EntityExistsException: Violation of PRIMARY
> KEY constraint 'PK__j3_categ__3213E83FD3C84046'. Cannot insert duplicate key
> in object 'dbo.j3_category_bag'. The duplicate key value is (902). {prepstmnt
> 1928491676 INSERT INTO j3_category_bag (id) VALUES (?)} [code=2627,
> state=23000]
> FailedObject:
> [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7]
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4959)
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4934)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:134)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:76)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:144)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:100)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:88)
> at
> org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:203)
> at
> org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:89)
> at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:104)
> at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:77)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:732)
>
[jira] [Updated] (JUDDI-1012) MS SQL Server Sequence table change
[ https://issues.apache.org/jira/browse/JUDDI-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1012: -- Fix Version/s: (was: 3.3.8) 3.3.9 > MS SQL Server Sequence table change > --- > > Key: JUDDI-1012 > URL: https://issues.apache.org/jira/browse/JUDDI-1012 > Project: jUDDI > Issue Type: Improvement > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > SQL Server 2012 is the oldest version that is supported by Microsoft. This > and newer versions support sequences. > > File mssql2000.ddl: > > create table hibernate_sequence (next_val numeric(19,0)); > Multiple instances of insert into hibernate_sequence values ( 1 ); > > Suggestion to change this to: > create sequence hibernate_sequence start with 1 increment by 1; > > To remove the sequence use: DROP sequence hibernate_sequence; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1009) Browse Businesses using juddiv2 page navigation issue
[ https://issues.apache.org/jira/browse/JUDDI-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1009: -- Fix Version/s: (was: 3.3.8) 3.3.9 > Browse Businesses using juddiv2 page navigation issue > - > > Key: JUDDI-1009 > URL: https://issues.apache.org/jira/browse/JUDDI-1009 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > Attachments: Business List v2.png > > > Browse Businesses using the default (v3) works properly. Total records shows > 473 businesses. Paging through the records with the right arrow button > properly moves you to the next set of 20 businesses. > > Select juddiv2 as the active configuration. Browse Businesses. Total > records shows 20 businesses. Paging trough the records lets you go 1 page > forward showing an offset of 20. The records displayed are the same 20 on > the first page with offset 0. > > This issue is present for Services and tModels. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1008) find_business returns an error when querying a tModel when using the v2 Inquire API
[ https://issues.apache.org/jira/browse/JUDDI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1008: -- Fix Version/s: (was: 3.3.8) 3.3.9 > find_business returns an error when querying a tModel when using the v2 > Inquire API > --- > > Key: JUDDI-1008 > URL: https://issues.apache.org/jira/browse/JUDDI-1008 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > The v2 Inquire API find_business returns an error when querying for a tModel. > The v3 call gives a valid response. > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > > soap:Server > At least one search criterion must be supplied. Try using > '%' as a wild card with the a 'approximateMatch' find qualifer for > everything > > operator="uddi:juddi.apache.org:node1" truncated="false"> > > A serious technical error has > occurred while processing the request. > > > > > > > > V3 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V3 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > xmlns:ns10="urn:uddi-org:vs_v3" xmlns:ns9="urn:uddi-org:repl_v3" > xmlns:ns8="urn:uddi-org:policy_v3" xmlns:ns7="urn:uddi-org:custody_v3" > xmlns:ns6="urn:uddi-org:subr_v3" xmlns:ns5="urn:uddi-org:sub_v3" > xmlns:ns4="urn:uddi-org:vscache_v3" > xmlns:ns3="http://www.w3.org/2000/09/xmldsig#; > xmlns:ns2="urn:uddi-org:api_v3" truncated="false"> > > 1 > 1 > 1 > > > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Provider > > serviceKey="uddi:juddi.apache.org:249f327a-68bd-4cd7-b358-c0347369e573" > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Service > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1010) save_business does not properly save the accessPoint URLType when using the v2 Publish API
[ https://issues.apache.org/jira/browse/JUDDI-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1010: -- Fix Version/s: (was: 3.3.8) 3.3.9 > save_business does not properly save the accessPoint URLType when using the > v2 Publish API > -- > > Key: JUDDI-1010 > URL: https://issues.apache.org/jira/browse/JUDDI-1010 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > The v2 Publish API – save_business does not save the values passed in for the > accessPoint URLType in the database, endpoint is always put in the DB. The > response from the v2 call includes the proper values for the accessPoint > URLType. The v3 call saves the accessPoint URLType properly. Note the value > for the authtoken was changed in the example XML. > > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > authtoken:ZZZ > > Test Provider > > > Test Service > > > URLType="http">http://somedomain.com/testservice.svc > > tModelKey="uuid:ee846ebf-ef30-4e73-8558-0eba166d002a" /> > > > > URLType="mailto">mailto:t...@domain.com > > tModelKey="uuid:f05b5947-8831-4c6a-9aa3-009ce5e6a707" /> > > > > > > > tModelKey="uuid:578a72bd-8f35-4099-b559-8b4997389bc5" keyName="DUNS" > keyValue="12-345-6781" /> > > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > operator="uddi:juddi.apache.org:node1" truncated="false"> > operator="uddi:juddi.apache.org:node1"> > Test Provider > > serviceKey="uddi:juddi.apache.org:99a4c6f6-c7f9-4536-a810-73c60f605a97"> > Test Service > > bindingKey="uddi:juddi.apache.org:2c3da830-751a-4304-8da4-006dd0d0007e"> > URLType="http">http://somedomain.com/testservice.svc > > tModelKey="uuid:ee846ebf-ef30-4e73-8558-0eba166d002a"/> > > > bindingKey="uddi:juddi.apache.org:c859a269-fefb-4f32-9047-e3de41b36900"> > URLType="mailto">mailto:t...@domain.com > > tModelKey="uuid:f05b5947-8831-4c6a-9aa3-009ce5e6a707"/> > > > > > > > tModelKey="uuid:578a72bd-8f35-4099-b559-8b4997389bc5" keyName="DUNS" > keyValue="12-345-6781"/> > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1014) Binding Editor – tModel Instance Information
[ https://issues.apache.org/jira/browse/JUDDI-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1014: -- Fix Version/s: (was: 3.3.8) 3.3.9 > Binding Editor – tModel Instance Information > > > Key: JUDDI-1014 > URL: https://issues.apache.org/jira/browse/JUDDI-1014 > Project: jUDDI > Issue Type: Improvement > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > Attachments: tModel Instance Info.png > > > It would be nice to display the tModel Name as you most likely will not know > what each tModel the GUID is for. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1015) Oracle database start up issue due to max string length
[
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree resolved JUDDI-1015.
---
Resolution: Fixed
> Oracle database start up issue due to max string length
> ---
>
> Key: JUDDI-1015
> URL: https://issues.apache.org/jira/browse/JUDDI-1015
> Project: jUDDI
> Issue Type: Bug
>Reporter: Alex O'Ree
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.9
>
>
> from the juddi mailing list
>
> {color:#172b4d}Oracle Version of Juddi Due to string limit for a column
> CREATE TABLE j3_binding_template (entity_key VARCHAR2(255) NOT NULL,
> access_point_type VARCHAR2(255), access_point_url VARCHAR2(4096),
> hosting_redirector VARCHAR2(255), service_key VARCHAR2(255) NOT NULL, PRIMARY
> KEY (entity_key)) {color}*Oracle max varchar limit: 4000*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JUDDI-1015) Oracle database start up issue due to max string length
[
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176710#comment-17176710
]
Alex O'Ree commented on JUDDI-1015:
---
pretty sure this is fixed. i'll leave it open for a few more days to hear back
from the folks on the mailing list that reporting this. it can always be
reopened after the release is cut
> Oracle database start up issue due to max string length
> ---
>
> Key: JUDDI-1015
> URL: https://issues.apache.org/jira/browse/JUDDI-1015
> Project: jUDDI
> Issue Type: Bug
>Reporter: Alex O'Ree
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.9
>
>
> from the juddi mailing list
>
> {color:#172b4d}Oracle Version of Juddi Due to string limit for a column
> CREATE TABLE j3_binding_template (entity_key VARCHAR2(255) NOT NULL,
> access_point_type VARCHAR2(255), access_point_url VARCHAR2(4096),
> hosting_redirector VARCHAR2(255), service_key VARCHAR2(255) NOT NULL, PRIMARY
> KEY (entity_key)) {color}*Oracle max varchar limit: 4000*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JUDDI-1016) Add DDL generators for all available hibernate supported dialetcs
[ https://issues.apache.org/jira/browse/JUDDI-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1016. --- Assignee: Alex O'Ree Resolution: Fixed > Add DDL generators for all available hibernate supported dialetcs > - > > Key: JUDDI-1016 > URL: https://issues.apache.org/jira/browse/JUDDI-1016 > Project: jUDDI > Issue Type: Improvement >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1011) MS SQL Server table - length of field too large
[ https://issues.apache.org/jira/browse/JUDDI-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1011. --- Resolution: Fixed > MS SQL Server table - length of field too large > --- > > Key: JUDDI-1011 > URL: https://issues.apache.org/jira/browse/JUDDI-1011 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > File mssql2000.ddl > > create table j3_tmodel_instance_info (id numeric(19,0) not null, > instance_parms varchar(8192), tmodel_key varchar(255) not null, entity_key > varchar(255) not null, primary key (id)); > > The instance_parms column exceeds the maximum length of a varchar field in > SQL Server of 8000 characters. I’ve reviewed the scripts for the other > database engines and the best option is to define this column as > instance_parms varchar(max). Another option is to define this column as > instance_parms varchar(8000) although if there was a good reason to make it > 8192 this value could overflow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JUDDI-1016) Add DDL generators for all available hibernate supported dialetcs
Alex O'Ree created JUDDI-1016: - Summary: Add DDL generators for all available hibernate supported dialetcs Key: JUDDI-1016 URL: https://issues.apache.org/jira/browse/JUDDI-1016 Project: jUDDI Issue Type: Improvement Reporter: Alex O'Ree Fix For: 3.3.9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (JUDDI-1011) MS SQL Server table - length of field too large
[ https://issues.apache.org/jira/browse/JUDDI-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JUDDI-1011 started by Alex O'Ree. - > MS SQL Server table - length of field too large > --- > > Key: JUDDI-1011 > URL: https://issues.apache.org/jira/browse/JUDDI-1011 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > File mssql2000.ddl > > create table j3_tmodel_instance_info (id numeric(19,0) not null, > instance_parms varchar(8192), tmodel_key varchar(255) not null, entity_key > varchar(255) not null, primary key (id)); > > The instance_parms column exceeds the maximum length of a varchar field in > SQL Server of 8000 characters. I’ve reviewed the scripts for the other > database engines and the best option is to define this column as > instance_parms varchar(max). Another option is to define this column as > instance_parms varchar(8000) although if there was a good reason to make it > 8192 this value could overflow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (JUDDI-1015) Oracle database start up issue due to max string length
[
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on JUDDI-1015 started by Alex O'Ree.
-
> Oracle database start up issue due to max string length
> ---
>
> Key: JUDDI-1015
> URL: https://issues.apache.org/jira/browse/JUDDI-1015
> Project: jUDDI
> Issue Type: Bug
>Reporter: Alex O'Ree
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.9
>
>
> from the juddi mailing list
>
> {color:#172b4d}Oracle Version of Juddi Due to string limit for a column
> CREATE TABLE j3_binding_template (entity_key VARCHAR2(255) NOT NULL,
> access_point_type VARCHAR2(255), access_point_url VARCHAR2(4096),
> hosting_redirector VARCHAR2(255), service_key VARCHAR2(255) NOT NULL, PRIMARY
> KEY (entity_key)) {color}*Oracle max varchar limit: 4000*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (JUDDI-1011) MS SQL Server table - length of field too large
[ https://issues.apache.org/jira/browse/JUDDI-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree reassigned JUDDI-1011: - Assignee: Alex O'Ree > MS SQL Server table - length of field too large > --- > > Key: JUDDI-1011 > URL: https://issues.apache.org/jira/browse/JUDDI-1011 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.9 > > > File mssql2000.ddl > > create table j3_tmodel_instance_info (id numeric(19,0) not null, > instance_parms varchar(8192), tmodel_key varchar(255) not null, entity_key > varchar(255) not null, primary key (id)); > > The instance_parms column exceeds the maximum length of a varchar field in > SQL Server of 8000 characters. I’ve reviewed the scripts for the other > database engines and the best option is to define this column as > instance_parms varchar(max). Another option is to define this column as > instance_parms varchar(8000) although if there was a good reason to make it > 8192 this value could overflow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1015) Oracle database start up issue due to max string length
[
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree updated JUDDI-1015:
--
Fix Version/s: (was: 3.3.8)
3.3.9
> Oracle database start up issue due to max string length
> ---
>
> Key: JUDDI-1015
> URL: https://issues.apache.org/jira/browse/JUDDI-1015
> Project: jUDDI
> Issue Type: Bug
>Reporter: Alex O'Ree
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.9
>
>
> from the juddi mailing list
>
> {color:#172b4d}Oracle Version of Juddi Due to string limit for a column
> CREATE TABLE j3_binding_template (entity_key VARCHAR2(255) NOT NULL,
> access_point_type VARCHAR2(255), access_point_url VARCHAR2(4096),
> hosting_redirector VARCHAR2(255), service_key VARCHAR2(255) NOT NULL, PRIMARY
> KEY (entity_key)) {color}*Oracle max varchar limit: 4000*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JUDDI-1011) MS SQL Server table - length of field too large
[ https://issues.apache.org/jira/browse/JUDDI-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1011: -- Fix Version/s: 3.3.9 > MS SQL Server table - length of field too large > --- > > Key: JUDDI-1011 > URL: https://issues.apache.org/jira/browse/JUDDI-1011 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Steve Luisser >Priority: Major > Fix For: 3.3.9 > > > File mssql2000.ddl > > create table j3_tmodel_instance_info (id numeric(19,0) not null, > instance_parms varchar(8192), tmodel_key varchar(255) not null, entity_key > varchar(255) not null, primary key (id)); > > The instance_parms column exceeds the maximum length of a varchar field in > SQL Server of 8000 characters. I’ve reviewed the scripts for the other > database engines and the best option is to define this column as > instance_parms varchar(max). Another option is to define this column as > instance_parms varchar(8000) although if there was a good reason to make it > 8192 this value could overflow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1014) Binding Editor – tModel Instance Information
[ https://issues.apache.org/jira/browse/JUDDI-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1014: -- Fix Version/s: 3.3.8 > Binding Editor – tModel Instance Information > > > Key: JUDDI-1014 > URL: https://issues.apache.org/jira/browse/JUDDI-1014 > Project: jUDDI > Issue Type: Improvement > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.8 > > Attachments: tModel Instance Info.png > > > It would be nice to display the tModel Name as you most likely will not know > what each tModel the GUID is for. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1014) Binding Editor – tModel Instance Information
[ https://issues.apache.org/jira/browse/JUDDI-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1014. --- Resolution: Fixed > Binding Editor – tModel Instance Information > > > Key: JUDDI-1014 > URL: https://issues.apache.org/jira/browse/JUDDI-1014 > Project: jUDDI > Issue Type: Improvement > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.8 > > Attachments: tModel Instance Info.png > > > It would be nice to display the tModel Name as you most likely will not know > what each tModel the GUID is for. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JUDDI-1014) Binding Editor – tModel Instance Information
[ https://issues.apache.org/jira/browse/JUDDI-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160832#comment-17160832 ] Alex O'Ree commented on JUDDI-1014: --- i think i have a solution for tmodel instance info. i can probably be applied to call tmodel picker calls if needed > Binding Editor – tModel Instance Information > > > Key: JUDDI-1014 > URL: https://issues.apache.org/jira/browse/JUDDI-1014 > Project: jUDDI > Issue Type: Improvement > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Attachments: tModel Instance Info.png > > > It would be nice to display the tModel Name as you most likely will not know > what each tModel the GUID is for. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1009) Browse Businesses using juddiv2 page navigation issue
[ https://issues.apache.org/jira/browse/JUDDI-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1009. --- Resolution: Fixed > Browse Businesses using juddiv2 page navigation issue > - > > Key: JUDDI-1009 > URL: https://issues.apache.org/jira/browse/JUDDI-1009 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.8 > > Attachments: Business List v2.png > > > Browse Businesses using the default (v3) works properly. Total records shows > 473 businesses. Paging through the records with the right arrow button > properly moves you to the next set of 20 businesses. > > Select juddiv2 as the active configuration. Browse Businesses. Total > records shows 20 businesses. Paging trough the records lets you go 1 page > forward showing an offset of 20. The records displayed are the same 20 on > the first page with offset 0. > > This issue is present for Services and tModels. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1009) Browse Businesses using juddiv2 page navigation issue
[ https://issues.apache.org/jira/browse/JUDDI-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1009: -- Fix Version/s: 3.3.8 > Browse Businesses using juddiv2 page navigation issue > - > > Key: JUDDI-1009 > URL: https://issues.apache.org/jira/browse/JUDDI-1009 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.8 > > Attachments: Business List v2.png > > > Browse Businesses using the default (v3) works properly. Total records shows > 473 businesses. Paging through the records with the right arrow button > properly moves you to the next set of 20 businesses. > > Select juddiv2 as the active configuration. Browse Businesses. Total > records shows 20 businesses. Paging trough the records lets you go 1 page > forward showing an offset of 20. The records displayed are the same 20 on > the first page with offset 0. > > This issue is present for Services and tModels. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (JUDDI-1009) Browse Businesses using juddiv2 page navigation issue
[ https://issues.apache.org/jira/browse/JUDDI-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JUDDI-1009 started by Alex O'Ree. - > Browse Businesses using juddiv2 page navigation issue > - > > Key: JUDDI-1009 > URL: https://issues.apache.org/jira/browse/JUDDI-1009 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Attachments: Business List v2.png > > > Browse Businesses using the default (v3) works properly. Total records shows > 473 businesses. Paging through the records with the right arrow button > properly moves you to the next set of 20 businesses. > > Select juddiv2 as the active configuration. Browse Businesses. Total > records shows 20 businesses. Paging trough the records lets you go 1 page > forward showing an offset of 20. The records displayed are the same 20 on > the first page with offset 0. > > This issue is present for Services and tModels. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (JUDDI-1014) Binding Editor – tModel Instance Information
[ https://issues.apache.org/jira/browse/JUDDI-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JUDDI-1014 started by Alex O'Ree. - > Binding Editor – tModel Instance Information > > > Key: JUDDI-1014 > URL: https://issues.apache.org/jira/browse/JUDDI-1014 > Project: jUDDI > Issue Type: Improvement > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Attachments: tModel Instance Info.png > > > It would be nice to display the tModel Name as you most likely will not know > what each tModel the GUID is for. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work stopped] (JUDDI-1014) Binding Editor – tModel Instance Information
[ https://issues.apache.org/jira/browse/JUDDI-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JUDDI-1014 stopped by Alex O'Ree. - > Binding Editor – tModel Instance Information > > > Key: JUDDI-1014 > URL: https://issues.apache.org/jira/browse/JUDDI-1014 > Project: jUDDI > Issue Type: Improvement > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Attachments: tModel Instance Info.png > > > It would be nice to display the tModel Name as you most likely will not know > what each tModel the GUID is for. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JUDDI-1011) MS SQL Server table - length of field too large
[ https://issues.apache.org/jira/browse/JUDDI-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17156157#comment-17156157 ] Alex O'Ree commented on JUDDI-1011: --- updating hibernate + using the ddl generator for newer versions of mssql, it does in fact use varchar(max) now. I found a few other fields that may have similar issues. This caused a few other unexpected issues with running queries on those fields. see the linked Jira for more information. > MS SQL Server table - length of field too large > --- > > Key: JUDDI-1011 > URL: https://issues.apache.org/jira/browse/JUDDI-1011 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Steve Luisser >Priority: Major > > File mssql2000.ddl > > create table j3_tmodel_instance_info (id numeric(19,0) not null, > instance_parms varchar(8192), tmodel_key varchar(255) not null, entity_key > varchar(255) not null, primary key (id)); > > The instance_parms column exceeds the maximum length of a varchar field in > SQL Server of 8000 characters. I’ve reviewed the scripts for the other > database engines and the best option is to define this column as > instance_parms varchar(max). Another option is to define this column as > instance_parms varchar(8000) although if there was a good reason to make it > 8192 this value could overflow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1008) find_business returns an error when querying a tModel when using the v2 Inquire API
[ https://issues.apache.org/jira/browse/JUDDI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1008. --- Resolution: Fixed > find_business returns an error when querying a tModel when using the v2 > Inquire API > --- > > Key: JUDDI-1008 > URL: https://issues.apache.org/jira/browse/JUDDI-1008 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.8 > > > The v2 Inquire API find_business returns an error when querying for a tModel. > The v3 call gives a valid response. > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > > soap:Server > At least one search criterion must be supplied. Try using > '%' as a wild card with the a 'approximateMatch' find qualifer for > everything > > operator="uddi:juddi.apache.org:node1" truncated="false"> > > A serious technical error has > occurred while processing the request. > > > > > > > > V3 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V3 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > xmlns:ns10="urn:uddi-org:vs_v3" xmlns:ns9="urn:uddi-org:repl_v3" > xmlns:ns8="urn:uddi-org:policy_v3" xmlns:ns7="urn:uddi-org:custody_v3" > xmlns:ns6="urn:uddi-org:subr_v3" xmlns:ns5="urn:uddi-org:sub_v3" > xmlns:ns4="urn:uddi-org:vscache_v3" > xmlns:ns3="http://www.w3.org/2000/09/xmldsig#; > xmlns:ns2="urn:uddi-org:api_v3" truncated="false"> > > 1 > 1 > 1 > > > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Provider > > serviceKey="uddi:juddi.apache.org:249f327a-68bd-4cd7-b358-c0347369e573" > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Service > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1008) find_business returns an error when querying a tModel when using the v2 Inquire API
[ https://issues.apache.org/jira/browse/JUDDI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1008: -- Fix Version/s: 3.3.8 > find_business returns an error when querying a tModel when using the v2 > Inquire API > --- > > Key: JUDDI-1008 > URL: https://issues.apache.org/jira/browse/JUDDI-1008 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.8 > > > The v2 Inquire API find_business returns an error when querying for a tModel. > The v3 call gives a valid response. > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > > soap:Server > At least one search criterion must be supplied. Try using > '%' as a wild card with the a 'approximateMatch' find qualifer for > everything > > operator="uddi:juddi.apache.org:node1" truncated="false"> > > A serious technical error has > occurred while processing the request. > > > > > > > > V3 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V3 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > xmlns:ns10="urn:uddi-org:vs_v3" xmlns:ns9="urn:uddi-org:repl_v3" > xmlns:ns8="urn:uddi-org:policy_v3" xmlns:ns7="urn:uddi-org:custody_v3" > xmlns:ns6="urn:uddi-org:subr_v3" xmlns:ns5="urn:uddi-org:sub_v3" > xmlns:ns4="urn:uddi-org:vscache_v3" > xmlns:ns3="http://www.w3.org/2000/09/xmldsig#; > xmlns:ns2="urn:uddi-org:api_v3" truncated="false"> > > 1 > 1 > 1 > > > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Provider > > serviceKey="uddi:juddi.apache.org:249f327a-68bd-4cd7-b358-c0347369e573" > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Service > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JUDDI-1008) find_business returns an error when querying a tModel when using the v2 Inquire API
[ https://issues.apache.org/jira/browse/JUDDI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17156155#comment-17156155 ] Alex O'Ree commented on JUDDI-1008: --- confirmed bug, easy fix, test case added > find_business returns an error when querying a tModel when using the v2 > Inquire API > --- > > Key: JUDDI-1008 > URL: https://issues.apache.org/jira/browse/JUDDI-1008 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.8 > > > The v2 Inquire API find_business returns an error when querying for a tModel. > The v3 call gives a valid response. > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > > soap:Server > At least one search criterion must be supplied. Try using > '%' as a wild card with the a 'approximateMatch' find qualifer for > everything > > operator="uddi:juddi.apache.org:node1" truncated="false"> > > A serious technical error has > occurred while processing the request. > > > > > > > > V3 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V3 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > xmlns:ns10="urn:uddi-org:vs_v3" xmlns:ns9="urn:uddi-org:repl_v3" > xmlns:ns8="urn:uddi-org:policy_v3" xmlns:ns7="urn:uddi-org:custody_v3" > xmlns:ns6="urn:uddi-org:subr_v3" xmlns:ns5="urn:uddi-org:sub_v3" > xmlns:ns4="urn:uddi-org:vscache_v3" > xmlns:ns3="http://www.w3.org/2000/09/xmldsig#; > xmlns:ns2="urn:uddi-org:api_v3" truncated="false"> > > 1 > 1 > 1 > > > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Provider > > serviceKey="uddi:juddi.apache.org:249f327a-68bd-4cd7-b358-c0347369e573" > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Service > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (JUDDI-1008) find_business returns an error when querying a tModel when using the v2 Inquire API
[ https://issues.apache.org/jira/browse/JUDDI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JUDDI-1008 started by Alex O'Ree. - > find_business returns an error when querying a tModel when using the v2 > Inquire API > --- > > Key: JUDDI-1008 > URL: https://issues.apache.org/jira/browse/JUDDI-1008 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > > The v2 Inquire API find_business returns an error when querying for a tModel. > The v3 call gives a valid response. > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > > soap:Server > At least one search criterion must be supplied. Try using > '%' as a wild card with the a 'approximateMatch' find qualifer for > everything > > operator="uddi:juddi.apache.org:node1" truncated="false"> > > A serious technical error has > occurred while processing the request. > > > > > > > > V3 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V3 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > xmlns:ns10="urn:uddi-org:vs_v3" xmlns:ns9="urn:uddi-org:repl_v3" > xmlns:ns8="urn:uddi-org:policy_v3" xmlns:ns7="urn:uddi-org:custody_v3" > xmlns:ns6="urn:uddi-org:subr_v3" xmlns:ns5="urn:uddi-org:sub_v3" > xmlns:ns4="urn:uddi-org:vscache_v3" > xmlns:ns3="http://www.w3.org/2000/09/xmldsig#; > xmlns:ns2="urn:uddi-org:api_v3" truncated="false"> > > 1 > 1 > 1 > > > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Provider > > serviceKey="uddi:juddi.apache.org:249f327a-68bd-4cd7-b358-c0347369e573" > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Service > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (JUDDI-1008) find_business returns an error when querying a tModel when using the v2 Inquire API
[ https://issues.apache.org/jira/browse/JUDDI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree reassigned JUDDI-1008: - Assignee: Alex O'Ree > find_business returns an error when querying a tModel when using the v2 > Inquire API > --- > > Key: JUDDI-1008 > URL: https://issues.apache.org/jira/browse/JUDDI-1008 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > > The v2 Inquire API find_business returns an error when querying for a tModel. > The v3 call gives a valid response. > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > > soap:Server > At least one search criterion must be supplied. Try using > '%' as a wild card with the a 'approximateMatch' find qualifer for > everything > > operator="uddi:juddi.apache.org:node1" truncated="false"> > > A serious technical error has > occurred while processing the request. > > > > > > > > V3 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V3 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > xmlns:ns10="urn:uddi-org:vs_v3" xmlns:ns9="urn:uddi-org:repl_v3" > xmlns:ns8="urn:uddi-org:policy_v3" xmlns:ns7="urn:uddi-org:custody_v3" > xmlns:ns6="urn:uddi-org:subr_v3" xmlns:ns5="urn:uddi-org:sub_v3" > xmlns:ns4="urn:uddi-org:vscache_v3" > xmlns:ns3="http://www.w3.org/2000/09/xmldsig#; > xmlns:ns2="urn:uddi-org:api_v3" truncated="false"> > > 1 > 1 > 1 > > > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Provider > > serviceKey="uddi:juddi.apache.org:249f327a-68bd-4cd7-b358-c0347369e573" > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Service > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JUDDI-1008) find_business returns an error when querying a tModel when using the v2 Inquire API
[ https://issues.apache.org/jira/browse/JUDDI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155835#comment-17155835 ] Alex O'Ree edited comment on JUDDI-1008 at 7/11/20, 3:04 AM: - i'm mean seriously, this is by far the best error reporting i've seen in a while! was (Author: spyhunter99): i'm mean serious, this is by far the best error reporting i've seen in a while! > find_business returns an error when querying a tModel when using the v2 > Inquire API > --- > > Key: JUDDI-1008 > URL: https://issues.apache.org/jira/browse/JUDDI-1008 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Priority: Major > > The v2 Inquire API find_business returns an error when querying for a tModel. > The v3 call gives a valid response. > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > > soap:Server > At least one search criterion must be supplied. Try using > '%' as a wild card with the a 'approximateMatch' find qualifer for > everything > > operator="uddi:juddi.apache.org:node1" truncated="false"> > > A serious technical error has > occurred while processing the request. > > > > > > > > V3 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V3 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > xmlns:ns10="urn:uddi-org:vs_v3" xmlns:ns9="urn:uddi-org:repl_v3" > xmlns:ns8="urn:uddi-org:policy_v3" xmlns:ns7="urn:uddi-org:custody_v3" > xmlns:ns6="urn:uddi-org:subr_v3" xmlns:ns5="urn:uddi-org:sub_v3" > xmlns:ns4="urn:uddi-org:vscache_v3" > xmlns:ns3="http://www.w3.org/2000/09/xmldsig#; > xmlns:ns2="urn:uddi-org:api_v3" truncated="false"> > > 1 > 1 > 1 > > > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Provider > > serviceKey="uddi:juddi.apache.org:249f327a-68bd-4cd7-b358-c0347369e573" > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Service > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JUDDI-1008) find_business returns an error when querying a tModel when using the v2 Inquire API
[ https://issues.apache.org/jira/browse/JUDDI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155835#comment-17155835 ] Alex O'Ree commented on JUDDI-1008: --- i'm mean serious, this is by far the best error reporting i've seen in a while! > find_business returns an error when querying a tModel when using the v2 > Inquire API > --- > > Key: JUDDI-1008 > URL: https://issues.apache.org/jira/browse/JUDDI-1008 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Priority: Major > > The v2 Inquire API find_business returns an error when querying for a tModel. > The v3 call gives a valid response. > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > > soap:Server > At least one search criterion must be supplied. Try using > '%' as a wild card with the a 'approximateMatch' find qualifer for > everything > > operator="uddi:juddi.apache.org:node1" truncated="false"> > > A serious technical error has > occurred while processing the request. > > > > > > > > V3 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > > keyName="DUNS" keyValue="12-345-6781" /> > > > > > > V3 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > xmlns:ns10="urn:uddi-org:vs_v3" xmlns:ns9="urn:uddi-org:repl_v3" > xmlns:ns8="urn:uddi-org:policy_v3" xmlns:ns7="urn:uddi-org:custody_v3" > xmlns:ns6="urn:uddi-org:subr_v3" xmlns:ns5="urn:uddi-org:sub_v3" > xmlns:ns4="urn:uddi-org:vscache_v3" > xmlns:ns3="http://www.w3.org/2000/09/xmldsig#; > xmlns:ns2="urn:uddi-org:api_v3" truncated="false"> > > 1 > 1 > 1 > > > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Provider > > serviceKey="uddi:juddi.apache.org:249f327a-68bd-4cd7-b358-c0347369e573" > businessKey="uddi:juddi.apache.org:0a528283-47f9-4bf8-b29c-1c1e0338fe28"> > Test Service > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JUDDI-1009) Browse Businesses using juddiv2 page navigation issue
[ https://issues.apache.org/jira/browse/JUDDI-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155834#comment-17155834 ] Alex O'Ree commented on JUDDI-1009: --- so the root problem here is that the v2 API has a field for max rows but for not for offset. i'm not sure what right looks like here. may increase the default max rows? that would result in more scrolling but the data would be accessible up to the limit. > Browse Businesses using juddiv2 page navigation issue > - > > Key: JUDDI-1009 > URL: https://issues.apache.org/jira/browse/JUDDI-1009 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Attachments: Business List v2.png > > > Browse Businesses using the default (v3) works properly. Total records shows > 473 businesses. Paging through the records with the right arrow button > properly moves you to the next set of 20 businesses. > > Select juddiv2 as the active configuration. Browse Businesses. Total > records shows 20 businesses. Paging trough the records lets you go 1 page > forward showing an offset of 20. The records displayed are the same 20 on > the first page with offset 0. > > This issue is present for Services and tModels. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JUDDI-1009) Browse Businesses using juddiv2 page navigation issue
[ https://issues.apache.org/jira/browse/JUDDI-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155829#comment-17155829 ] Alex O'Ree commented on JUDDI-1009: --- [~sluisser] the quality and detail of your bug reports are awesome! much appreciated. > Browse Businesses using juddiv2 page navigation issue > - > > Key: JUDDI-1009 > URL: https://issues.apache.org/jira/browse/JUDDI-1009 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Attachments: Business List v2.png > > > Browse Businesses using the default (v3) works properly. Total records shows > 473 businesses. Paging through the records with the right arrow button > properly moves you to the next set of 20 businesses. > > Select juddiv2 as the active configuration. Browse Businesses. Total > records shows 20 businesses. Paging trough the records lets you go 1 page > forward showing an offset of 20. The records displayed are the same 20 on > the first page with offset 0. > > This issue is present for Services and tModels. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1012) MS SQL Server Sequence table change
[ https://issues.apache.org/jira/browse/JUDDI-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1012. --- Fix Version/s: 3.3.8 Assignee: Alex O'Ree Resolution: Fixed > MS SQL Server Sequence table change > --- > > Key: JUDDI-1012 > URL: https://issues.apache.org/jira/browse/JUDDI-1012 > Project: jUDDI > Issue Type: Improvement > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.8 > > > SQL Server 2012 is the oldest version that is supported by Microsoft. This > and newer versions support sequences. > > File mssql2000.ddl: > > create table hibernate_sequence (next_val numeric(19,0)); > Multiple instances of insert into hibernate_sequence values ( 1 ); > > Suggestion to change this to: > create sequence hibernate_sequence start with 1 increment by 1; > > To remove the sequence use: DROP sequence hibernate_sequence; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JUDDI-1012) MS SQL Server Sequence table change
[ https://issues.apache.org/jira/browse/JUDDI-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155826#comment-17155826 ] Alex O'Ree commented on JUDDI-1012: --- confirmed, the newer version of hibernate has a bunch of more dialects for different versions of sql server. I've added automated generation for the other versions and the output is exactly as you described. > MS SQL Server Sequence table change > --- > > Key: JUDDI-1012 > URL: https://issues.apache.org/jira/browse/JUDDI-1012 > Project: jUDDI > Issue Type: Improvement > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Priority: Major > > SQL Server 2012 is the oldest version that is supported by Microsoft. This > and newer versions support sequences. > > File mssql2000.ddl: > > create table hibernate_sequence (next_val numeric(19,0)); > Multiple instances of insert into hibernate_sequence values ( 1 ); > > Suggestion to change this to: > create sequence hibernate_sequence start with 1 increment by 1; > > To remove the sequence use: DROP sequence hibernate_sequence; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1004) JUDDI-3.3.7 With SQL Server Database Gives Primary Key Violation For Table j3_category_bag
[
https://issues.apache.org/jira/browse/JUDDI-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree resolved JUDDI-1004.
---
Fix Version/s: 3.3.8
Resolution: Fixed
I'm going to tag this as fixed for the timing being since action was taken on
it but i don't have the ability to reproduce the issue.
> JUDDI-3.3.7 With SQL Server Database Gives Primary Key Violation For Table
> j3_category_bag
> ---
>
> Key: JUDDI-1004
> URL: https://issues.apache.org/jira/browse/JUDDI-1004
> Project: jUDDI
> Issue Type: Bug
> Components: core, juddi-tomcat
>Affects Versions: 3.3.7
>Reporter: Amol Bhonsle
>Priority: Major
> Labels: jUDDI, juddi
> Fix For: 3.3.8
>
>
> Our application is based on JUDDI-3.3.7 When we try to publishService() we
> get following Exception:
>
>
> Caused by:
> org.apache.openjpa.persistence.RollbackException: The transaction has been
> rolled back. See the nested exceptions for details on the errors that
> occurred.
> FailedObject:
> [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7]
> at
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:594)
> at
> org.apache.juddi.api.impl.UDDIPublicationImpl.saveService(UDDIPublicationImpl.java:892)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179)
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.performInvocation(JAXWSMethodInvoker.java:66)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
> ... 42 more
> Caused by:
> org.apache.openjpa.persistence.PersistenceException: The transaction has been
> rolled back. See the nested exceptions for details on the errors that
> occurred.
> FailedObject:
> [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7]
> at
> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2370)
> at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2207)
> at
> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2105)
> at
> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:2023)
> at
> org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
> at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1528)
> at
> org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:933)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:570)
> ... 50 more
> Caused by:
> org.apache.openjpa.persistence.EntityExistsException: Violation of PRIMARY
> KEY constraint 'PK__j3_categ__3213E83FD3C84046'. Cannot insert duplicate key
> in object 'dbo.j3_category_bag'. The duplicate key value is (902). {prepstmnt
> 1928491676 INSERT INTO j3_category_bag (id) VALUES (?)} [code=2627,
> state=23000]
> FailedObject:
> [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7]
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4959)
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4934)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:134)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:76)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:144)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:100)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:88)
> at
> org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:203)
> at
> org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:89)
> at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:104)
> at
>
[jira] [Resolved] (JUDDI-1010) save_business does not properly save the accessPoint URLType when using the v2 Publish API
[ https://issues.apache.org/jira/browse/JUDDI-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1010. --- Fix Version/s: 3.3.8 Assignee: Alex O'Ree Resolution: Fixed this should be resolved via JUDDI-1006 > save_business does not properly save the accessPoint URLType when using the > v2 Publish API > -- > > Key: JUDDI-1010 > URL: https://issues.apache.org/jira/browse/JUDDI-1010 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.8 > > > The v2 Publish API – save_business does not save the values passed in for the > accessPoint URLType in the database, endpoint is always put in the DB. The > response from the v2 call includes the proper values for the accessPoint > URLType. The v3 call saves the accessPoint URLType properly. Note the value > for the authtoken was changed in the example XML. > > V2 Request > > http://schemas.xmlsoap.org/soap/envelope/; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xmlns:xsd="http://www.w3.org/2001/XMLSchema;> > > > authtoken:ZZZ > > Test Provider > > > Test Service > > > URLType="http">http://somedomain.com/testservice.svc > > tModelKey="uuid:ee846ebf-ef30-4e73-8558-0eba166d002a" /> > > > > URLType="mailto">mailto:t...@domain.com > > tModelKey="uuid:f05b5947-8831-4c6a-9aa3-009ce5e6a707" /> > > > > > > > tModelKey="uuid:578a72bd-8f35-4099-b559-8b4997389bc5" keyName="DUNS" > keyValue="12-345-6781" /> > > > > > > > V2 Response > http://schemas.xmlsoap.org/soap/envelope/;> > > operator="uddi:juddi.apache.org:node1" truncated="false"> > operator="uddi:juddi.apache.org:node1"> > Test Provider > > serviceKey="uddi:juddi.apache.org:99a4c6f6-c7f9-4536-a810-73c60f605a97"> > Test Service > > bindingKey="uddi:juddi.apache.org:2c3da830-751a-4304-8da4-006dd0d0007e"> > URLType="http">http://somedomain.com/testservice.svc > > tModelKey="uuid:ee846ebf-ef30-4e73-8558-0eba166d002a"/> > > > bindingKey="uddi:juddi.apache.org:c859a269-fefb-4f32-9047-e3de41b36900"> > URLType="mailto">mailto:t...@domain.com > > tModelKey="uuid:f05b5947-8831-4c6a-9aa3-009ce5e6a707"/> > > > > > > > tModelKey="uuid:578a72bd-8f35-4099-b559-8b4997389bc5" keyName="DUNS" > keyValue="12-345-6781"/> > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JUDDI-1011) MS SQL Server table - length of field too large
[ https://issues.apache.org/jira/browse/JUDDI-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155816#comment-17155816 ] Alex O'Ree commented on JUDDI-1011: --- unfortunately the reason for the 8192 value was the UDDIv3 spec itself. While we can deviate from the spec, I'd rather not. I've linked a few other related tickets. In JUDDI-999 was to add the @Lob annotation which should have change the column to some kind of blob. I'll check on the DDL generator. We are using a slightly older version of hibernate to make the scripts. A newer version may fix it. They may also have dialects for a newer version of mssql now too > MS SQL Server table - length of field too large > --- > > Key: JUDDI-1011 > URL: https://issues.apache.org/jira/browse/JUDDI-1011 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Steve Luisser >Priority: Major > > File mssql2000.ddl > > create table j3_tmodel_instance_info (id numeric(19,0) not null, > instance_parms varchar(8192), tmodel_key varchar(255) not null, entity_key > varchar(255) not null, primary key (id)); > > The instance_parms column exceeds the maximum length of a varchar field in > SQL Server of 8000 characters. I’ve reviewed the scripts for the other > database engines and the best option is to define this column as > instance_parms varchar(max). Another option is to define this column as > instance_parms varchar(8000) although if there was a good reason to make it > 8192 this value could overflow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JUDDI-1012) MS SQL Server Sequence table change
[ https://issues.apache.org/jira/browse/JUDDI-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155814#comment-17155814 ] Alex O'Ree commented on JUDDI-1012: --- so our DDL files are actually generated from the source code using some tooling. I'll check to see if there's a newer version we can jump too that may produce a newer/better result > MS SQL Server Sequence table change > --- > > Key: JUDDI-1012 > URL: https://issues.apache.org/jira/browse/JUDDI-1012 > Project: jUDDI > Issue Type: Improvement > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Priority: Major > > SQL Server 2012 is the oldest version that is supported by Microsoft. This > and newer versions support sequences. > > File mssql2000.ddl: > > create table hibernate_sequence (next_val numeric(19,0)); > Multiple instances of insert into hibernate_sequence values ( 1 ); > > Suggestion to change this to: > create sequence hibernate_sequence start with 1 increment by 1; > > To remove the sequence use: DROP sequence hibernate_sequence; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1013) GUI adding records
[ https://issues.apache.org/jira/browse/JUDDI-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1013: -- Fix Version/s: 3.3.8 > GUI adding records > -- > > Key: JUDDI-1013 > URL: https://issues.apache.org/jira/browse/JUDDI-1013 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.8 > > > Create a business and save it. Navigate to the Services to add a service. > You see the message “Please save the business first, then you can add > services.” You need to open the business again before you can add a service. > This behavior occurs at multiple levels as you go deeper into the business > definition. It does not seem like the page is refreshing to know that the > data has been saved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1013) GUI adding records
[ https://issues.apache.org/jira/browse/JUDDI-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1013. --- Resolution: Fixed > GUI adding records > -- > > Key: JUDDI-1013 > URL: https://issues.apache.org/jira/browse/JUDDI-1013 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > Fix For: 3.3.8 > > > Create a business and save it. Navigate to the Services to add a service. > You see the message “Please save the business first, then you can add > services.” You need to open the business again before you can add a service. > This behavior occurs at multiple levels as you go deeper into the business > definition. It does not seem like the page is refreshing to know that the > data has been saved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JUDDI-1015) Oracle database start up issue due to max string length
[
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155813#comment-17155813
]
Alex O'Ree commented on JUDDI-1015:
---
[~kurtstam] may need your help with this one. After changing the columns, looks
like find business based on discovery url barfs with the following:
ERROR: Comparisons between 'CLOB (UCS_BASIC)' and 'CLOB (UCS_BASIC)' are not
supported. Types must be comparable. String types must also have matching
collation. If collation does not match, a possible solution is to cast operands
to force them to the default collation (e.g. SELECT tablename FROM
sys.systables WHERE CAST(tablename AS VARCHAR(128)) = 'T1')
Jul 10, 2020 9:17:44 PM org.apache.juddi.v3.tck.TckFindEntity findBusiness
SEVERE: org.hibernate.exception.SQLGrammarException: could not prepare statement
javax.persistence.PersistenceException:
org.hibernate.exception.SQLGrammarException: could not prepare statement
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692)
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602)
at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492)
at org.apache.juddi.query.EntityQuery.getQueryResult(EntityQuery.java:163)
at
org.apache.juddi.query.FindBusinessByDiscoveryURLQuery.select(FindBusinessByDiscoveryURLQuery.java:75)
at org.apache.juddi.api.impl.InquiryHelper.findBusiness(InquiryHelper.java:206)
at
org.apache.juddi.api.impl.UDDIInquiryImpl.findBusiness(UDDIInquiryImpl.java:211)
at org.apache.juddi.v3.tck.TckFindEntity.findBusiness(TckFindEntity.java:89)
at
org.apache.juddi.api.impl.API_070_FindEntityTest.findEntities(API_070_FindEntityTest.java:96)
I'm not super sure how to apply this type of cast using the current query
mechanisms that we have. Any ideas?
> Oracle database start up issue due to max string length
> ---
>
> Key: JUDDI-1015
> URL: https://issues.apache.org/jira/browse/JUDDI-1015
> Project: jUDDI
> Issue Type: Bug
>Reporter: Alex O'Ree
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.8
>
>
> from the juddi mailing list
>
> {color:#172b4d}Oracle Version of Juddi Due to string limit for a column
> CREATE TABLE j3_binding_template (entity_key VARCHAR2(255) NOT NULL,
> access_point_type VARCHAR2(255), access_point_url VARCHAR2(4096),
> hosting_redirector VARCHAR2(255), service_key VARCHAR2(255) NOT NULL, PRIMARY
> KEY (entity_key)) {color}*Oracle max varchar limit: 4000*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work stopped] (JUDDI-1015) Oracle database start up issue due to max string length
[
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on JUDDI-1015 stopped by Alex O'Ree.
-
> Oracle database start up issue due to max string length
> ---
>
> Key: JUDDI-1015
> URL: https://issues.apache.org/jira/browse/JUDDI-1015
> Project: jUDDI
> Issue Type: Bug
>Reporter: Alex O'Ree
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.8
>
>
> from the juddi mailing list
>
> {color:#172b4d}Oracle Version of Juddi Due to string limit for a column
> CREATE TABLE j3_binding_template (entity_key VARCHAR2(255) NOT NULL,
> access_point_type VARCHAR2(255), access_point_url VARCHAR2(4096),
> hosting_redirector VARCHAR2(255), service_key VARCHAR2(255) NOT NULL, PRIMARY
> KEY (entity_key)) {color}*Oracle max varchar limit: 4000*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JUDDI-1015) Oracle database start up issue due to max string length
[
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree updated JUDDI-1015:
--
Fix Version/s: 3.3.8
> Oracle database start up issue due to max string length
> ---
>
> Key: JUDDI-1015
> URL: https://issues.apache.org/jira/browse/JUDDI-1015
> Project: jUDDI
> Issue Type: Bug
>Reporter: Alex O'Ree
>Priority: Major
> Fix For: 3.3.8
>
>
> from the juddi mailing list
>
> {color:#172b4d}Oracle Version of Juddi Due to string limit for a column
> CREATE TABLE j3_binding_template (entity_key VARCHAR2(255) NOT NULL,
> access_point_type VARCHAR2(255), access_point_url VARCHAR2(4096),
> hosting_redirector VARCHAR2(255), service_key VARCHAR2(255) NOT NULL, PRIMARY
> KEY (entity_key)) {color}*Oracle max varchar limit: 4000*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (JUDDI-1015) Oracle database start up issue due to max string length
[
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree reassigned JUDDI-1015:
-
Assignee: Alex O'Ree
> Oracle database start up issue due to max string length
> ---
>
> Key: JUDDI-1015
> URL: https://issues.apache.org/jira/browse/JUDDI-1015
> Project: jUDDI
> Issue Type: Bug
>Reporter: Alex O'Ree
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.8
>
>
> from the juddi mailing list
>
> {color:#172b4d}Oracle Version of Juddi Due to string limit for a column
> CREATE TABLE j3_binding_template (entity_key VARCHAR2(255) NOT NULL,
> access_point_type VARCHAR2(255), access_point_url VARCHAR2(4096),
> hosting_redirector VARCHAR2(255), service_key VARCHAR2(255) NOT NULL, PRIMARY
> KEY (entity_key)) {color}*Oracle max varchar limit: 4000*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work started] (JUDDI-1015) Oracle database start up issue due to max string length
[
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on JUDDI-1015 started by Alex O'Ree.
-
> Oracle database start up issue due to max string length
> ---
>
> Key: JUDDI-1015
> URL: https://issues.apache.org/jira/browse/JUDDI-1015
> Project: jUDDI
> Issue Type: Bug
>Reporter: Alex O'Ree
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.8
>
>
> from the juddi mailing list
>
> {color:#172b4d}Oracle Version of Juddi Due to string limit for a column
> CREATE TABLE j3_binding_template (entity_key VARCHAR2(255) NOT NULL,
> access_point_type VARCHAR2(255), access_point_url VARCHAR2(4096),
> hosting_redirector VARCHAR2(255), service_key VARCHAR2(255) NOT NULL, PRIMARY
> KEY (entity_key)) {color}*Oracle max varchar limit: 4000*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JUDDI-1013) GUI adding records
[ https://issues.apache.org/jira/browse/JUDDI-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151156#comment-17151156 ] Alex O'Ree commented on JUDDI-1013: --- i believe this commits resolve this condition, although it really looses the "saved" confirmation message. what are you thoughts on this? it just reloads the page immediately after the save > GUI adding records > -- > > Key: JUDDI-1013 > URL: https://issues.apache.org/jira/browse/JUDDI-1013 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > > Create a business and save it. Navigate to the Services to add a service. > You see the message “Please save the business first, then you can add > services.” You need to open the business again before you can add a service. > This behavior occurs at multiple levels as you go deeper into the business > definition. It does not seem like the page is refreshing to know that the > data has been saved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (JUDDI-1013) GUI adding records
[ https://issues.apache.org/jira/browse/JUDDI-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JUDDI-1013 started by Alex O'Ree. - > GUI adding records > -- > > Key: JUDDI-1013 > URL: https://issues.apache.org/jira/browse/JUDDI-1013 > Project: jUDDI > Issue Type: Bug > Components: juddi-gui >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Assignee: Alex O'Ree >Priority: Major > > Create a business and save it. Navigate to the Services to add a service. > You see the message “Please save the business first, then you can add > services.” You need to open the business again before you can add a service. > This behavior occurs at multiple levels as you go deeper into the business > definition. It does not seem like the page is refreshing to know that the > data has been saved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1007) Not saving an Access Point Type correctly in the database when using juddiv2
[ https://issues.apache.org/jira/browse/JUDDI-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1007. --- Resolution: Fixed > Not saving an Access Point Type correctly in the database when using juddiv2 > > > Key: JUDDI-1007 > URL: https://issues.apache.org/jira/browse/JUDDI-1007 > Project: jUDDI > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Steve Luisser >Priority: Major > > Using juddi default (v3) you can create an access point type of Mailto which > saves to the database and is displayed properly in the UI. When using > juddiv2, the access point type displays as endpoint. > > Using juddiv2 create an Access Point using a random binding template key, > access point type "Mailto" and Access Point Value: "mailto:t...@email.com; > and save the access point. The value endPoint is saved in the database, not > Mailto. If the database contains a value of Mailto in the access_point_type > field, it still displays endPoint in the UI. > > Note that the response from the v2 Inquire API returns the value of mailto if > this value is in the database. > URLType="mailto">[mailto:t...@email.commailto:t...@email.com%3c/ns2:accessPoint]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1006) Saving an Access Point Type
[ https://issues.apache.org/jira/browse/JUDDI-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1006: -- Fix Version/s: 3.3.9 > Saving an Access Point Type > --- > > Key: JUDDI-1006 > URL: https://issues.apache.org/jira/browse/JUDDI-1006 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Alex O'Ree >Priority: Minor > Fix For: 3.3.9 > > > Using juddi default (v3) you can create an access point type of Mailto which > saves to the database and is displayed properly in the UI. When using > juddiv2, the access point type displays as endpoint. > > Using juddiv2 create an Access Point using a random binding template key, > access point type “Mailto” and Access Point Value: > “[[t...@email.com|mailto:[t...@email.com]|mailto:t...@email.com]” and save > the access point. The value endPoint is saved in the database, not Mailto. > If the database contains a value of Mailto in the access_point_type field, it > still displays endPoint in the UI. > > Note that the response from the v2 Inquire API returns the value of mailto if > this value is in the database. > URLType="mailto">[mailto:t...@email.commailto:t...@email.com%3c/ns2:accessPoint]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1006) Saving an Access Point Type
[ https://issues.apache.org/jira/browse/JUDDI-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree resolved JUDDI-1006. --- Assignee: Alex O'Ree Resolution: Fixed > Saving an Access Point Type > --- > > Key: JUDDI-1006 > URL: https://issues.apache.org/jira/browse/JUDDI-1006 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Alex O'Ree >Assignee: Alex O'Ree >Priority: Minor > Fix For: 3.3.9 > > > Using juddi default (v3) you can create an access point type of Mailto which > saves to the database and is displayed properly in the UI. When using > juddiv2, the access point type displays as endpoint. > > Using juddiv2 create an Access Point using a random binding template key, > access point type “Mailto” and Access Point Value: > “[[t...@email.com|mailto:[t...@email.com]|mailto:t...@email.com]” and save > the access point. The value endPoint is saved in the database, not Mailto. > If the database contains a value of Mailto in the access_point_type field, it > still displays endPoint in the UI. > > Note that the response from the v2 Inquire API returns the value of mailto if > this value is in the database. > URLType="mailto">[mailto:t...@email.commailto:t...@email.com%3c/ns2:accessPoint]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JUDDI-1006) Saving an Access Point Type
[ https://issues.apache.org/jira/browse/JUDDI-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JUDDI-1006: -- Description: Using juddi default (v3) you can create an access point type of Mailto which saves to the database and is displayed properly in the UI. When using juddiv2, the access point type displays as endpoint. Using juddiv2 create an Access Point using a random binding template key, access point type “Mailto” and Access Point Value: “[[t...@email.com|mailto:[t...@email.com]|mailto:t...@email.com]” and save the access point. The value endPoint is saved in the database, not Mailto. If the database contains a value of Mailto in the access_point_type field, it still displays endPoint in the UI. Note that the response from the v2 Inquire API returns the value of mailto if this value is in the database. [mailto:t...@email.commailto:t...@email.com%3c/ns2:accessPoint]> was: Using juddi default (v3) you can create an access point type of Mailto which saves to the database and is displayed properly in the UI. When using juddiv2, the access point type displays as endpoint. ++ ++ Using juddiv2 create an Access Point using a random binding template key, access point type “Mailto” and Access Point Value: “mailto:[t...@email.com|mailto:t...@email.com]” and save the access point. The value endPoint is saved in the database, not Mailto. If the database contains a value of Mailto in the access_point_type field, it still displays endPoint in the UI. ++ ++ Note that the response from the v2 Inquire API returns the value of mailto if this value is in the database. [mailto:t...@email.commailto:t...@email.com%3c/ns2:accessPoint]> > Saving an Access Point Type > --- > > Key: JUDDI-1006 > URL: https://issues.apache.org/jira/browse/JUDDI-1006 > Project: jUDDI > Issue Type: Bug > Components: core >Reporter: Alex O'Ree >Priority: Minor > > Using juddi default (v3) you can create an access point type of Mailto which > saves to the database and is displayed properly in the UI. When using > juddiv2, the access point type displays as endpoint. > > Using juddiv2 create an Access Point using a random binding template key, > access point type “Mailto” and Access Point Value: > “[[t...@email.com|mailto:[t...@email.com]|mailto:t...@email.com]” and save > the access point. The value endPoint is saved in the database, not Mailto. > If the database contains a value of Mailto in the access_point_type field, it > still displays endPoint in the UI. > > Note that the response from the v2 Inquire API returns the value of mailto if > this value is in the database. > URLType="mailto">[mailto:t...@email.commailto:t...@email.com%3c/ns2:accessPoint]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JUDDI-1006) Saving an Access Point Type
Alex O'Ree created JUDDI-1006: - Summary: Saving an Access Point Type Key: JUDDI-1006 URL: https://issues.apache.org/jira/browse/JUDDI-1006 Project: jUDDI Issue Type: Bug Components: core Reporter: Alex O'Ree Using juddi default (v3) you can create an access point type of Mailto which saves to the database and is displayed properly in the UI. When using juddiv2, the access point type displays as endpoint. ++ ++ Using juddiv2 create an Access Point using a random binding template key, access point type “Mailto” and Access Point Value: “mailto:[t...@email.com|mailto:t...@email.com]” and save the access point. The value endPoint is saved in the database, not Mailto. If the database contains a value of Mailto in the access_point_type field, it still displays endPoint in the UI. ++ ++ Note that the response from the v2 Inquire API returns the value of mailto if this value is in the database. [mailto:t...@email.commailto:t...@email.com%3c/ns2:accessPoint]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JUDDI-1003) spring-web jar supplied with latest JUDDI distribution has security vulnerability
[
https://issues.apache.org/jira/browse/JUDDI-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree resolved JUDDI-1003.
---
Resolution: Fixed
> spring-web jar supplied with latest JUDDI distribution has security
> vulnerability
> -
>
> Key: JUDDI-1003
> URL: https://issues.apache.org/jira/browse/JUDDI-1003
> Project: jUDDI
> Issue Type: Bug
> Components: juddi-tomcat
>Affects Versions: 3.3.6, 3.3.7
>Reporter: Amol Bhonsle
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.8
>
>
> The jar for spring-web (JUDDI 3.3.7 comes with spring-web-3.2.18.RELEASE)
> which is provided in distribution has following Security Vulnerability.
>
> The {{org.springframework:spring-web}} package is vulnerable to
> deserialization of untrusted data leading to Remote Code Execution (RCE).
> The {{readRemoteInvocation}} method in {{HttpInvokerServiceExporter.class}}
> does not properly verify or restrict untrusted objects prior to deserializing
> them. An attacker can exploit this vulnerability by sending malicious
> requests containing crafted objects, which when deserialized, execute
> arbitrary code on the vulnerable system.
>
> The {{spring-core}} and {{spring-web}} modules of Spring Framework are
> vulnerable to a multipart content pollution vulnerability. The
> {{generateMultipartBoundary()}} method in the {{MimeTypeUtils}} class uses a
> predictable method of generating random values to use as boundary values for
> multipart requests to other servers. This means that an attacker may be able
> to predict the boundary values and inject them into requests at unexpected
> locations, causing the recipient server to incorrectly interpret the
> multipart request. This will result in unexpected behavior depending on the
> requests being processed, including privilege escalation if authorization
> data is sent in the multipart request.
> Note:
> {quote}In order for the attacker to succeed, they would have to be able to
> guess the multipart boundary value chosen by server A for the multipart
> request to server B, which requires the attacker to also have control of the
> server or the ability to see the HTTP log of server A through a separate
> attack vector.
> {quote}
>
> Spring Framework is vulnerable to Cross-Site Tracing (XST) attacks. The
> {{HiddenHttpMethodFilter}} class lets an attacker change the HTTP request
> method to {{TRACE}}. An attacker can exploit this behavior with an Cross-Site
> Scripting (XSS) attack by sending a TRACE request and recovering information
> that would not normally be accessible, such as Cookies with the HTTPOnly flag.
>
> Please check and provide fix for this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JUDDI-1005) Need To have correct options to upgrade JUDDI DB Schema
[
https://issues.apache.org/jira/browse/JUDDI-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039614#comment-17039614
]
Alex O'Ree commented on JUDDI-1005:
---
it should be in
[uddi-client-distro-3.3.7.zip|http://apache.claz.org/juddi/juddi/3.3.7/uddi-client-distro-3.3.7.zip]
> Need To have correct options to upgrade JUDDI DB Schema
> ---
>
> Key: JUDDI-1005
> URL: https://issues.apache.org/jira/browse/JUDDI-1005
> Project: jUDDI
> Issue Type: Bug
> Components: juddi-tomcat
>Affects Versions: 3.3.6, 3.3.7
>Reporter: Amol Bhonsle
>Priority: Major
> Attachments:
> uddi-migration-tool-3.3.8-SNAPSHOT-jar-with-dependencies.jar
>
>
> We are trying to update JUDDI DB from JUDDI-3.0.4 to JUDDI-3.3.7. JUDDI DB is
> hosted on SQL Server. We use openjpa-2.3.0 which is provided by juddi-3.3.7
> distribution.
>
> As per openjpa-2.3.0 documentation:
> {{drop option of SchemaTool should do following:}}
> {{drop}}: Drop all schema components in the schema XML. Tables will only be
> dropped if they would have 0 columns after dropping all columns listed in the
> XML.
> and add option should do following:
> {{add}}: This is the default action if you do not specify one. It brings the
> schema up-to-date with the given XML document by adding tables, columns,
> indexes, etc. This action never drops any schema components.
> Also it is allowed in persistence.xml to use options as comma separated, so
> we tried following option in persistence.xml to drop old tables and create
> new tables as per juddi-3.3.7 schema but it did not work:
> value="buildSchema(SchemaAction='drop,add')"/>
>
> This gives following Exception when JUDDI is deployed by tomcat :
>
> {code:java}
> SEVERE: Exception sending context initialized event to listener instance of
> class org.springframework.web.context.ContextLoaderListenerSEVERE: Exception
> sending context initialized event to listener instance of class
> org.springframework.web.context.ContextLoaderListenerorg.springframework.beans.factory.BeanCreationException:
> Error creating bean with name 'inquiry': Cannot create inner bean '(inner
> bean)#fa6535a' of type [org.apache.juddi.api.impl.UDDIInquiryImpl] while
> setting constructor argument; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name '(inner bean)#fa6535a': Instantiation of bean failed; nested
> exception is org.springframework.beans.BeanInstantiationException: Failed to
> instantiate [org.apache.juddi.api.impl.UDDIInquiryImpl]: Constructor threw
> exception; nested exception is general error> org.apache.openjpa.persistence.PersistenceException: The
> object 'PK__j3_clerk__5609ADDDCF01D08E' is dependent on column 'clerk_name'.
> \{stmnt 1807668378 ALTER TABLE j3_clerk DROP COLUMN clerk_name} [code=5074,
> state=S0001] at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:389)
> at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:134)
> at
> org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:691)
> at
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:196)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1358)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1204)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:557)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$208/1654431226.getObject(Unknown
> Source) at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:879)
> at
>
[jira] [Commented] (JUDDI-1005) Need To have correct options to upgrade JUDDI DB Schema
[
https://issues.apache.org/jira/browse/JUDDI-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039613#comment-17039613
]
Alex O'Ree commented on JUDDI-1005:
---
just attached the correct jar, sorry about that.
> Need To have correct options to upgrade JUDDI DB Schema
> ---
>
> Key: JUDDI-1005
> URL: https://issues.apache.org/jira/browse/JUDDI-1005
> Project: jUDDI
> Issue Type: Bug
> Components: juddi-tomcat
>Affects Versions: 3.3.6, 3.3.7
>Reporter: Amol Bhonsle
>Priority: Major
> Attachments:
> uddi-migration-tool-3.3.8-SNAPSHOT-jar-with-dependencies.jar
>
>
> We are trying to update JUDDI DB from JUDDI-3.0.4 to JUDDI-3.3.7. JUDDI DB is
> hosted on SQL Server. We use openjpa-2.3.0 which is provided by juddi-3.3.7
> distribution.
>
> As per openjpa-2.3.0 documentation:
> {{drop option of SchemaTool should do following:}}
> {{drop}}: Drop all schema components in the schema XML. Tables will only be
> dropped if they would have 0 columns after dropping all columns listed in the
> XML.
> and add option should do following:
> {{add}}: This is the default action if you do not specify one. It brings the
> schema up-to-date with the given XML document by adding tables, columns,
> indexes, etc. This action never drops any schema components.
> Also it is allowed in persistence.xml to use options as comma separated, so
> we tried following option in persistence.xml to drop old tables and create
> new tables as per juddi-3.3.7 schema but it did not work:
> value="buildSchema(SchemaAction='drop,add')"/>
>
> This gives following Exception when JUDDI is deployed by tomcat :
>
> {code:java}
> SEVERE: Exception sending context initialized event to listener instance of
> class org.springframework.web.context.ContextLoaderListenerSEVERE: Exception
> sending context initialized event to listener instance of class
> org.springframework.web.context.ContextLoaderListenerorg.springframework.beans.factory.BeanCreationException:
> Error creating bean with name 'inquiry': Cannot create inner bean '(inner
> bean)#fa6535a' of type [org.apache.juddi.api.impl.UDDIInquiryImpl] while
> setting constructor argument; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name '(inner bean)#fa6535a': Instantiation of bean failed; nested
> exception is org.springframework.beans.BeanInstantiationException: Failed to
> instantiate [org.apache.juddi.api.impl.UDDIInquiryImpl]: Constructor threw
> exception; nested exception is general error> org.apache.openjpa.persistence.PersistenceException: The
> object 'PK__j3_clerk__5609ADDDCF01D08E' is dependent on column 'clerk_name'.
> \{stmnt 1807668378 ALTER TABLE j3_clerk DROP COLUMN clerk_name} [code=5074,
> state=S0001] at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:389)
> at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:134)
> at
> org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:691)
> at
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:196)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1358)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1204)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:557)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$208/1654431226.getObject(Unknown
> Source) at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:879)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:878)
> at
>
[jira] [Updated] (JUDDI-1005) Need To have correct options to upgrade JUDDI DB Schema
[
https://issues.apache.org/jira/browse/JUDDI-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex O'Ree updated JUDDI-1005:
--
Attachment: uddi-migration-tool-3.3.8-SNAPSHOT-jar-with-dependencies.jar
> Need To have correct options to upgrade JUDDI DB Schema
> ---
>
> Key: JUDDI-1005
> URL: https://issues.apache.org/jira/browse/JUDDI-1005
> Project: jUDDI
> Issue Type: Bug
> Components: juddi-tomcat
>Affects Versions: 3.3.6, 3.3.7
>Reporter: Amol Bhonsle
>Priority: Major
> Attachments:
> uddi-migration-tool-3.3.8-SNAPSHOT-jar-with-dependencies.jar
>
>
> We are trying to update JUDDI DB from JUDDI-3.0.4 to JUDDI-3.3.7. JUDDI DB is
> hosted on SQL Server. We use openjpa-2.3.0 which is provided by juddi-3.3.7
> distribution.
>
> As per openjpa-2.3.0 documentation:
> {{drop option of SchemaTool should do following:}}
> {{drop}}: Drop all schema components in the schema XML. Tables will only be
> dropped if they would have 0 columns after dropping all columns listed in the
> XML.
> and add option should do following:
> {{add}}: This is the default action if you do not specify one. It brings the
> schema up-to-date with the given XML document by adding tables, columns,
> indexes, etc. This action never drops any schema components.
> Also it is allowed in persistence.xml to use options as comma separated, so
> we tried following option in persistence.xml to drop old tables and create
> new tables as per juddi-3.3.7 schema but it did not work:
> value="buildSchema(SchemaAction='drop,add')"/>
>
> This gives following Exception when JUDDI is deployed by tomcat :
>
> {code:java}
> SEVERE: Exception sending context initialized event to listener instance of
> class org.springframework.web.context.ContextLoaderListenerSEVERE: Exception
> sending context initialized event to listener instance of class
> org.springframework.web.context.ContextLoaderListenerorg.springframework.beans.factory.BeanCreationException:
> Error creating bean with name 'inquiry': Cannot create inner bean '(inner
> bean)#fa6535a' of type [org.apache.juddi.api.impl.UDDIInquiryImpl] while
> setting constructor argument; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name '(inner bean)#fa6535a': Instantiation of bean failed; nested
> exception is org.springframework.beans.BeanInstantiationException: Failed to
> instantiate [org.apache.juddi.api.impl.UDDIInquiryImpl]: Constructor threw
> exception; nested exception is general error> org.apache.openjpa.persistence.PersistenceException: The
> object 'PK__j3_clerk__5609ADDDCF01D08E' is dependent on column 'clerk_name'.
> \{stmnt 1807668378 ALTER TABLE j3_clerk DROP COLUMN clerk_name} [code=5074,
> state=S0001] at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:389)
> at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:134)
> at
> org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:691)
> at
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:196)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1358)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1204)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:557)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$208/1654431226.getObject(Unknown
> Source) at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:879)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:878)
> at
>
[jira] [Commented] (JUDDI-1005) Need To have correct options to upgrade JUDDI DB Schema
[
https://issues.apache.org/jira/browse/JUDDI-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17038330#comment-17038330
]
Alex O'Ree commented on JUDDI-1005:
---
the migration tool will backup and uddi server and restore it to another. if
the jpa update mechanism fails, then this is the only mechanism i am aware of.
start juddi 304
run the migration tool is backup mode
stop juddi
drop the tables/databases
start the new juddi
run the migration tool in restore mode
obviously, take a snapshot t or backup first
[~kurt.s...@gmail.com] have any other ideas? i can't even get 304 to start up
with mssql, different jpa error...
> Need To have correct options to upgrade JUDDI DB Schema
> ---
>
> Key: JUDDI-1005
> URL: https://issues.apache.org/jira/browse/JUDDI-1005
> Project: jUDDI
> Issue Type: Bug
> Components: juddi-tomcat
>Affects Versions: 3.3.6, 3.3.7
>Reporter: Amol Bhonsle
>Priority: Major
>
> We are trying to update JUDDI DB from JUDDI-3.0.4 to JUDDI-3.3.7. JUDDI DB is
> hosted on SQL Server. We use openjpa-2.3.0 which is provided by juddi-3.3.7
> distribution.
>
> As per openjpa-2.3.0 documentation:
> {{drop option of SchemaTool should do following:}}
> {{drop}}: Drop all schema components in the schema XML. Tables will only be
> dropped if they would have 0 columns after dropping all columns listed in the
> XML.
> and add option should do following:
> {{add}}: This is the default action if you do not specify one. It brings the
> schema up-to-date with the given XML document by adding tables, columns,
> indexes, etc. This action never drops any schema components.
> Also it is allowed in persistence.xml to use options as comma separated, so
> we tried following option in persistence.xml to drop old tables and create
> new tables as per juddi-3.3.7 schema but it did not work:
> value="buildSchema(SchemaAction='drop,add')"/>
>
> This gives following Exception when JUDDI is deployed by tomcat :
>
> {code:java}
> SEVERE: Exception sending context initialized event to listener instance of
> class org.springframework.web.context.ContextLoaderListenerSEVERE: Exception
> sending context initialized event to listener instance of class
> org.springframework.web.context.ContextLoaderListenerorg.springframework.beans.factory.BeanCreationException:
> Error creating bean with name 'inquiry': Cannot create inner bean '(inner
> bean)#fa6535a' of type [org.apache.juddi.api.impl.UDDIInquiryImpl] while
> setting constructor argument; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name '(inner bean)#fa6535a': Instantiation of bean failed; nested
> exception is org.springframework.beans.BeanInstantiationException: Failed to
> instantiate [org.apache.juddi.api.impl.UDDIInquiryImpl]: Constructor threw
> exception; nested exception is general error> org.apache.openjpa.persistence.PersistenceException: The
> object 'PK__j3_clerk__5609ADDDCF01D08E' is dependent on column 'clerk_name'.
> \{stmnt 1807668378 ALTER TABLE j3_clerk DROP COLUMN clerk_name} [code=5074,
> state=S0001] at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:389)
> at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:134)
> at
> org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:691)
> at
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:196)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1358)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1204)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:557)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$208/1654431226.getObject(Unknown
> Source) at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321)
> at
>
