Bug 778436 (SOA-918) - Rel Notes - Document the potential issue with ACCESS_POINT_URL field
Summary: Rel Notes - Document the potential issue with ACCESS_POINT_URL field
Keywords:
Status: CLOSED NEXTRELEASE
Alias: SOA-918
Product: JBoss Enterprise SOA Platform 4
Classification: JBoss
Component: Documentation
Version: 4.3 IR5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.3 GA
Assignee: Dana Mison
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-06 11:00 UTC by Jiri Pechanec
Modified: 2008-10-28 08:13 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-28 08:13:11 UTC
Type: Feature Request


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 778437 0 high CLOSED The ESB EPRs can cause failure of registration of ESB service 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker SOA-918 0 None None None Never

Internal Links: 778437

Description Jiri Pechanec 2008-10-06 11:00:29 UTC
Date of First Response: 2008-10-06 23:01:30
project_key: SOA

The jUDDI be default sets the length of field ACCESS_POINT_URL  in binding_template table to 2000 chrs. Unfortunately the standard ESB EPRs length is close to the limit.
soaesb1=> select length(access_point_url) from binding_template;
 length
--------
   2615
   1562
   1556
   1550
   1548
   1545
   1546
   1552
   1549
   2615
(10 rows)

It should be docuemented in known issues that service registartion can fail due to this reason and as workaround the field size should be increased to 4000.

Comment 1 Jiri Pechanec 2008-10-06 11:04:14 UTC
Link: Added: This issue is related to SOA-919


Comment 2 Dana Mison 2008-10-07 03:01:30 UTC
I'm confused.  Am I looking at the wrong thing?

The only references I can find (in IR5) is this, which says the column is 255 characters, not 2000 , "ACCESS_POINT_URL VARCHAR(255) NULL"

jboss-as/server/production/deploy/juddi-service.sar/META-INF/ddl/juddi_create_db.ddl

CREATE TABLE BINDING_TEMPLATE ( SERVICE_KEY VARCHAR(41) NOT NULL, BINDING_KEY VARCHAR(41) NOT NULL, ACCESS_POINT_TYPE VARCHAR(20) NULL, ACCESS_POINT_URL VARCHAR(255) NULL, HOSTING_REDIRECTOR VARCHAR(255) NULL, LAST_UPDATE TIMESTAMP NOT NULL, PRIMARY KEY (BINDING_KEY), FOREIGN KEY (SERVICE_KEY) REFERENCES BUSINESS_SERVICE (SERVICE_KEY));



Comment 3 Jiri Pechanec 2008-10-07 03:49:41 UTC
Hi, the scripts are located in deploy/jbossesb.sar/lib/scout-*.jar

Comment 4 Mark Little 2008-10-09 17:43:26 UTC
What's the status?

Comment 5 Dana Mison 2008-10-13 08:14:34 UTC
Sorry still confused, I understand that the database column needs to be wider.

But I'm not sure how this relates to Scout as a JAXR provider?

Comment 6 Dana Mison 2008-10-14 08:19:44 UTC
Reply received by email:
"I saw your comment on this issue. I made a mistake by refering to deploy/jbossesb.sar/lib/scout-*.jar but correct is deploy/jbossesb.sar/lib/juddi-*.jar.
If you open the jar file you will see the SQL scripts with short column definition. The issue happens if the jUDDI is used as UDDI registry in ESB."

 

Comment 7 Dana Mison 2008-10-22 00:31:18 UTC
Service registration will fail if the length of the ESB EndPoint Reference (EPR) is greater than 2000 characters

jUDDI, the default UDDI registry, stores the EPR URL with a maximum size of 2000 characters as the size of most EPR URLs are expected to be slightly less than this.  However if the EPR URL is longer than 2000 characters the table insert will fail, causing the service registration to fail.  

A future update will address this by increasing this maximum.  

If this is an immediate problem then you can manually alter the column from its existing datatype of varchar(2000) to the recommended varchar(4000).  The table is binding_template,
the column is access_point_url.  Increasing the size to varchar(4000) should provide ample space.  If this table is already populated with data you should create a backup before attempting any changes.

Comment 8 Lukáš Petrovický 2008-10-28 08:13:11 UTC
This has been documented.


Note You need to log in before you can comment on or make changes to this bug.