[jira] [Work started] (JUDDI-1015) Oracle database start up issue due to max string length

2020-07-10 Thread Alex O'Ree (Jira)


 [ 
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] [Created] (JUDDI-1015) Oracle database start up issue due to max string length

2020-07-10 Thread Alex O'Ree (Jira)
Alex O'Ree created JUDDI-1015:
-

 Summary: 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


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

2020-07-10 Thread Alex O'Ree (Jira)


 [ 
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

2020-07-10 Thread Alex O'Ree (Jira)


 [ 
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)


Re: Support - JUDDIv3 issue on statrup of Tomcat

2020-07-10 Thread Alex O'Ree
JUDDI-999 similar problem, similar fix. Testing it now. Will be fixed in
the next version. I can provide a test build if you like or you can also
compile from source if you all are so equiped

On Wed, Jul 8, 2020 at 10:12 PM Alex O'Ree  wrote:

> Strange, I thought this was fixed. I'll take a look at this shortly. I
> think the fix is to use a blob data type for the this field
>
> On Wed, Jul 8, 2020 at 6:14 AM Rakesh Shelar <
> rakesh.she...@northgateps.com> wrote:
>
>> HI,
>>
>> We are looking for support on the following juddiv3 issue we are facing
>> on the startup of juddiv3 Tomcat.
>>
>> 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)) *Oracle max varchar limit: 4000*
>>
>> We have installed JUDDI 3.3.8 with Oracle 12c , OpenJDK11Hotspot, &
>> Tomcat 9.0.24
>>
>> Refer -
>>
>> http://juddi.apache.org/jacoco/juddi-core-openjpa/jacoco-ut/org.apache.juddi.model/BindingTemplate.java.html
>>
>> [image: image.png]
>>
>> Any suggestions?
>>
>> Regards,
>> Rakesh Shelar
>> Sr. Technical Architect - CONNECT (DevOps)
>> Mobile: +91 (0) 8657549870
>>  +44 7435826126
>> www.northgateps.com
>>
>> Follow us on: Twitter  / LinkedIn
>>  / YouTube
>>   / Google+
>> 
>>
>> Northgate Public Services (UK) Ltd
>>
>> This email is sent on behalf of Northgate Public Services (UK) Limited
>> and its associated companies including Rave Technologies (India) Pvt
>> Limited (together "Northgate Public Services") and is strictly confidential
>> and intended solely for the addressee(s).
>> If you are not the intended recipient of this email you must: (i) not
>> disclose, copy or distribute its contents to any other person nor use its
>> contents in any way or you may be acting unlawfully;  (ii) contact
>> Northgate Public Services immediately on +44(0)1442 768445 quoting the
>> name of the sender and the addressee then delete it from your system.
>> Northgate Public Services has taken reasonable precautions to ensure that
>> no viruses are contained in this email, but does not accept any
>> responsibility once this email has been transmitted.  You should scan
>> attachments (if any) for viruses.
>>
>> Northgate Public Services (UK) Limited, registered in England and Wales
>> under number 00968498 with a registered address of Peoplebuilding 2,
>> Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2
>> 4NW.  Rave Technologies (India) Pvt Limited, registered in India under
>> number U31900MH1998PTC117068 with a registered address of PLOT CS 445, 3
>> rd Floor, A-wing Madhu Corporate Park Ltd, Pandurang Budhkar Marg, Mumbai
>> -400013
>>
>


[jira] [Commented] (JUDDI-1015) Oracle database start up issue due to max string length

2020-07-10 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155812#comment-17155812
 ] 

ASF subversion and git services commented on JUDDI-1015:


Commit 7d562f926b974d46b5e0f9e76d774a10ff9dc889 in juddi's branch 
refs/heads/bug/JUDDI-1015 from Alex O'Ree
[ https://gitbox.apache.org/repos/asf?p=juddi.git;h=7d562f9 ]

JUDDI-1015 incomplete fix for certain columns being too long on specific 
database vendors (oracle in this case). this has some test failures and query 
issues due to the column type changes.


> 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

2020-07-10 Thread Alex O'Ree (Jira)


 [ 
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] [Commented] (JUDDI-1015) Oracle database start up issue due to max string length

2020-07-10 Thread Alex O'Ree (Jira)


[ 
https://issues.apache.org/jira/browse/JUDDI-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (JUDDI-1013) GUI adding records

2020-07-10 Thread Alex O'Ree (Jira)


 [ 
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

2020-07-10 Thread Alex O'Ree (Jira)


 [ 
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-1012) MS SQL Server Sequence table change

2020-07-10 Thread Alex O'Ree (Jira)


[ 
https://issues.apache.org/jira/browse/JUDDI-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (JUDDI-1011) MS SQL Server table - length of field too large

2020-07-10 Thread Alex O'Ree (Jira)


[ 
https://issues.apache.org/jira/browse/JUDDI-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (JUDDI-1010) save_business does not properly save the accessPoint URLType when using the v2 Publish API

2020-07-10 Thread Alex O'Ree (Jira)


 [ 
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] [Resolved] (JUDDI-1004) JUDDI-3.3.7 With SQL Server Database Gives Primary Key Violation For Table j3_category_bag

2020-07-10 Thread Alex O'Ree (Jira)


 [ 
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 
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(Abstrac

[jira] [Commented] (JUDDI-1012) MS SQL Server Sequence table change

2020-07-10 Thread Alex O'Ree (Jira)


[ 
https://issues.apache.org/jira/browse/JUDDI-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (JUDDI-1012) MS SQL Server Sequence table change

2020-07-10 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/JUDDI-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155828#comment-17155828
 ] 

ASF subversion and git services commented on JUDDI-1012:


Commit bad3192dddc3f4b168e6923da9f051616554c2ed in juddi's branch 
refs/heads/master from Alex O'Ree
[ https://gitbox.apache.org/repos/asf?p=juddi.git;h=bad3192 ]

JUDDI-1012 newer version of hibernate (jre8 min), also adds some additional 
DDLs for mssql and oracle


> 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-1012) MS SQL Server Sequence table change

2020-07-10 Thread Alex O'Ree (Jira)


 [ 
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-1009) Browse Businesses using juddiv2 page navigation issue

2020-07-10 Thread Alex O'Ree (Jira)


[ 
https://issues.apache.org/jira/browse/JUDDI-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (JUDDI-1009) Browse Businesses using juddiv2 page navigation issue

2020-07-10 Thread Alex O'Ree (Jira)


[ 
https://issues.apache.org/jira/browse/JUDDI-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-1008) find_business returns an error when querying a tModel when using the v2 Inquire API

2020-07-10 Thread Alex O'Ree (Jira)


[ 
https://issues.apache.org/jira/browse/JUDDI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (JUDDI-1008) find_business returns an error when querying a tModel when using the v2 Inquire API

2020-07-10 Thread Alex O'Ree (Jira)


[ 
https://issues.apache.org/jira/browse/JUDDI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)