-
Suggestion
-
Resolution: Fixed
-
Windows NT4 Server SP6 / Sybase 12.5 (NT) (with JConnect 5.2 JDBC Driver) / Tomcat 4.0.3 / JDK 1.3
Hi,
We'd like to run JIRA using Sybase as the datastore, although we know it is not tested by you. We have had some success with the field type definition file (below).
When we start Tomcat, JIRA creates all the tables without any problems. We get the initial setup page, but when we click to enter the admin user, we get NullPointerExceptions in the console and the browser is empty.
We have the environment set up and working fine on Oracle. We did this first, seeing as the field type definition file already existed for that database.
Have you any ideas what might be causing the problem? I cannot find anything on the web or here about using JIRA with Sybase.
Many thanks,
Michael Brown
FieldTypes
----------
<fieldtypemodel>
<!-- ===================== field-type-def ==================== -->
<!-- General Types -->
<field-type-def type="blob" sql-type="IMAGE" java-type="java.lang.Object"></field-type-def>
<field-type-def type="date-time" sql-type="DATETIME" java-type="java.sql.Timestamp"></field-type-def>
<field-type-def type="date" sql-type="DATETIME" java-type="java.sql.Date"></field-type-def>
<field-type-def type="time" sql-type="DATETIME" java-type="java.sql.Time"></field-type-def>
<field-type-def type="currency-amount" sql-type="NUMERIC(18,2)" java-type="Double"><validate name="isSignedDouble" /></field-type-def>
<field-type-def type="floating-point" sql-type="NUMERIC(18,6)" java-type="Double"><validate name="isSignedDouble" /></field-type-def>
<field-type-def type="numeric" sql-type="NUMERIC(18,0)" java-type="Long"><validate name="isSignedLong" /></field-type-def>
<field-type-def type="integer" sql-type="NUMERIC(9,0)" java-type="Integer"><validate name="isSignedLong" /></field-type-def>
<field-type-def type="id" sql-type="VARCHAR(20)" java-type="String"></field-type-def>
<field-type-def type="id-long" sql-type="VARCHAR(60)" java-type="String"></field-type-def>
<field-type-def type="id-vlong" sql-type="VARCHAR(255)" java-type="String"></field-type-def>
<field-type-def type="indicator" sql-type="CHAR(1)" java-type="String"></field-type-def>
<field-type-def type="very-short" sql-type="VARCHAR(10)" java-type="String"></field-type-def>
<field-type-def type="short-varchar" sql-type="VARCHAR(60)" java-type="String"></field-type-def>
<field-type-def type="long-varchar" sql-type="VARCHAR(255)" java-type="String"></field-type-def>
<field-type-def type="very-long" sql-type="VARCHAR(4000)" java-type="String"></field-type-def>
<field-type-def type="comment" sql-type="VARCHAR(255)" java-type="String"></field-type-def>
<field-type-def type="description" sql-type="VARCHAR(255)" java-type="String"></field-type-def>
<field-type-def type="name" sql-type="VARCHAR(60)" java-type="String"></field-type-def>
<field-type-def type="value" sql-type="VARCHAR(255)" java-type="String"></field-type-def>
<!-- Specialized Types -->
<field-type-def type="credit-card-number" sql-type="VARCHAR(40)" java-type="String"><validate name="isAnyCard" /></field-type-def>
<field-type-def type="credit-card-date" sql-type="VARCHAR(20)" java-type="String"><validate name="isDateAfterToday" /></field-type-def>
<field-type-def type="email" sql-type="VARCHAR(255)" java-type="String"><validate name="isEmail" /></field-type-def>
<field-type-def type="url" sql-type="VARCHAR(255)" java-type="String"></field-type-def>
<field-type-def type="id-ne" sql-type="VARCHAR(20)" java-type="String"><validate name="isNotEmpty" /></field-type-def>
<field-type-def type="id-long-ne" sql-type="VARCHAR(60)" java-type="String"><validate name="isNotEmpty" /></field-type-def>
<field-type-def type="id-vlong-ne" sql-type="VARCHAR(255)" java-type="String"><validate name="isNotEmpty" /></field-type-def>
<field-type-def type="tel-number" sql-type="VARCHAR(60)" java-type="String"><validate name="isInternationalPhoneNumber" /></field-type-def>
</fieldtypemodel>
Console log:
------------
Starting service Tomcat-Standalone
Apache Tomcat/4.0.3
2002-05-24 12:02:55,875 FATAL [core.entity.model.ModelReader] FINISHED LOADING E
NTITIES - ALL FILES; #Entities=22 #ViewEntities=0 #Fields=98 #Relationships=14
Starting service Tomcat-Apache
Apache Tomcat/4.0.3
java.lang.NullPointerException
at com.opensymphony.module.user.provider.ofbiz.OFBizAbstractProvider.fin
dUser(OFBizAbstractProvider.java:166)
at com.opensymphony.module.user.provider.ofbiz.OFBizProfileProvider.hand
les(OFBizProfileProvider.java:140)
at com.opensymphony.module.user.UserManager.getProvider(UserManager.java
:330)
at com.opensymphony.module.user.UserManager.access$1(UserManager.java)
at com.opensymphony.module.user.UserManager$Accessor.getProfileProvider(
UserManager.java:366)
at com.opensymphony.module.user.Entity.getProfileProvider(Entity.java:10
5)
at com.opensymphony.module.user.Entity.getPropertySet(Entity.java:59)
at com.opensymphony.module.user.User.getFullName(User.java:49)
at org.apache.jsp.insecure$jsp._jspService(insecure$jsp.java:323)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspSer
vlet.java:202)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
82)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:574)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:497)
at com.opensymphony.module.sitemesh.filter.PageFilter.applyDecorator(Unk
nown Source)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(Unknown S
ource)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
at com.atlassian.jira.web.security.SecurityFilter.doFilter(SecurityFilte
r.java:201)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
at com.atlassian.jira.web.security.LoginFilter.doFilter(LoginFilter.java
:189)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:190)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2343)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:180)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
468)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:174)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcesso
r.java:1012)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.ja
va:1107)
at java.lang.Thread.run(Thread.java:484)
- is related to
-
- Gathering Interest
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JRASERVER-413] Sybase support
Michael Phillimore-Brown
added a comment - Hi Grant,
That is great to hear, thank you. We're just using standalone at the moment, but it would be nice to use Sybase for peace of mind during audits if nothing else!
We'll give it a go soon,
Mike
Michael Phillimore-Brown
added a comment - Hi Grant,
That is great to hear, thank you. We're just using standalone at the moment, but it would be nice to use Sybase for peace of mind during audits if nothing else!
We'll give it a go soon,
Mike We've managed to get this working under Jira 1.4.3-#22. (And I've just got myself a login to this forum so I thought I'd make use of it...)
Under sybase 12.0.0.4, in particular ... (select @@version)
Adaptive Server Enterprise/12.0.0.4/P/SWR 9839 ROLLUP/Sun_svr4/OS 5.6/1777/32bit/FBO/Fri Nov 23 08:58:58 2001
I'll work out how to attach the field types file in a minute, but basically instead of using class name "java.sql.Timestamp" simply use "Timestamp" and everything seems to work.
Michael Phillimore-Brown
added a comment - Hi,
Is there any movement on the Sybase issues? Now we've bought the commercial license we're expecting to up the usage massively so we really need to nail this one. The current version is really, really close to working - it would be excellent (for you and us!) to have Sybase support in the bag.
Cheers,
Mike
Michael Phillimore-Brown
added a comment - Hi,
Is there any movement on the Sybase issues? Now we've bought the commercial license we're expecting to up the usage massively so we really need to nail this one. The current version is really, really close to working - it would be excellent (for you and us!) to have Sybase support in the bag.
Cheers,
Mike 
Greg Perrott
added a comment - I have retested JIRA with the very lastet JConnect 5.5 (JDBC 2 driver) and still have the same problem. See exceptions below:
org.ofbiz.core.entity.GenericEntityException: while updating: (Java type com.sybase.jdbc2.tds.SybTimestamp not currently supported. Sorry.)
org.ofbiz.core.entity.GenericNotImplementedException: Java type com.sybase.jdbc2.tds.SybTimestamp not currently supported. Sorry.
The only relevant Sybase Timestamp related issue that I could find on the Sybase web site was the following. This may be of some use:
jConnect 5.x no longer uses the deprecated constructors in java.sql.Timestamp, java.sql.Time and java.sql.Date.
We now use the constructors that take a long millisecond value. Additionally, jConnect 5.x no longer uses the deprecated setXXX and getXXX methods in the Timestamp, Time and Date classes. All setting is done through the suggested Calendar.set (field, value)methods.
Greg Perrott
added a comment - I have retested JIRA with the very lastet JConnect 5.5 (JDBC 2 driver) and still have the same problem. See exceptions below:
org.ofbiz.core.entity.GenericEntityException: while updating: (Java type com.sybase.jdbc2.tds.SybTimestamp not currently supported. Sorry.)
org.ofbiz.core.entity.GenericNotImplementedException: Java type com.sybase.jdbc2.tds.SybTimestamp not currently supported. Sorry.
The only relevant Sybase Timestamp related issue that I could find on the Sybase web site was the following. This may be of some use:
jConnect 5.x no longer uses the deprecated constructors in java.sql.Timestamp, java.sql.Time and java.sql.Date.
We now use the constructors that take a long millisecond value. Additionally, jConnect 5.x no longer uses the deprecated setXXX and getXXX methods in the Timestamp, Time and Date classes. All setting is done through the suggested Calendar.set (field, value)methods.
Mike Cannon-Brookes
added a comment - Greg,
OFBiz supports Timestamps fine (and we must use them because we need both date and time parts of the ts, not just date 
). All our code currently runs on Timestamps.
My belief is that there's a problem with the Sybase driver not handling or passing Timestamp's correctly to OFBiz (or something is getting lost in the middle). I'll have to take a deeper look at it - probably sometime next week.
Cheers,
Mike
Mike Cannon-Brookes
added a comment - Greg,
OFBiz supports Timestamps fine (and we must use them because we need both date and time parts of the ts, not just date ). All our code currently runs on Timestamps.
My belief is that there's a problem with the Sybase driver not handling or passing Timestamp's correctly to OFBiz (or something is getting lost in the middle). I'll have to take a deeper look at it - probably sometime next week.
Cheers,
Mike Greg Perrott
added a comment - I have had a go at getting JIRA to run with sybase using the field-type configuration from above and have the following suggestions.
Change the sql-type to "TEXT" for the "very-long" field-type. See the attched file. Sybase does no supprt VARCHAR fields over 255 characters.
The problem the lack of support for the java-type of "java.sql.Timestamp" appears to be a problem with the ofbiz framework. Is this correct? If so then I suggest that you change JIRA to use "java.sql.date" for the field-type of "date-time". I am not sure how this will impact other databases. Hhopefully not as both "date" and "date-time" field-types are defined as "java.sql.Datetime". This might enable JIRA to support Sybase now rather than waiting on changes to the ofbiz framework.
Currrently we are running JIRA over MySQL and are very keen to get it onto Sybase.
Greg Perrott
added a comment - I have had a go at getting JIRA to run with sybase using the field-type configuration from above and have the following suggestions.
Change the sql-type to "TEXT" for the "very-long" field-type. See the attched file. Sybase does no supprt VARCHAR fields over 255 characters.
The problem the lack of support for the java-type of "java.sql.Timestamp" appears to be a problem with the ofbiz framework. Is this correct? If so then I suggest that you change JIRA to use "java.sql.date" for the field-type of "date-time". I am not sure how this will impact other databases. Hhopefully not as both "date" and "date-time" field-types are defined as "java.sql.Datetime". This might enable JIRA to support Sybase now rather than waiting on changes to the ofbiz framework.
Currrently we are running JIRA over MySQL and are very keen to get it onto Sybase.
Michael Phillimore-Brown
added a comment - Hi again,
Yes the problem did seem to be that by default Sybase will not allow nulls in any column. In Sybase 12 there is an option to allow nulls by default when creating the database tables. I selected this and now JIRA is 98% fine.
There is an issue adding comments, however. Using Tomcat you get an error after you've added a comment (stack trace below). The weird thing is the comment gets added anyway...
Using Orion you also get a stack trace starting with 'java.lang.IllegalArgumentException: [GenericDelegator.refresh] could not refresh value: [GenericEntity:Action][body,asf][issue,10012][type,comment][author,mbrown][level,null][created,2002-05-28 16:52:39.515][id,10025]' and the comment does not get saved.
It looks to me like the ofbiz stuff doesn't quite work with Sybase at the moment, which is a shame as it's so close.
Another issue seems to be that Sybase is case sensitive when it comes to columns and table names and for some reason some columns are created in upper case and some in lower case. Anyway I think we're going to have to stick with Oracle for now but I hope this helps potential Sybase users.
Regards,
Mike
javax.servlet.ServletException: System error while executing class com.atlassian.jira.web.action.issue.AddComment
Root Cause:
org.ofbiz.core.entity.GenericNotImplementedException: Java type com.sybase.jdbc2.tds.SybTimestamp not currently supported. Sorry.
at org.ofbiz.core.entity.GenericDAO.setValue(GenericDAO.java:1833)
at org.ofbiz.core.entity.GenericDAO.singleUpdate(GenericDAO.java:277)
at org.ofbiz.core.entity.GenericDAO.singleStore(GenericDAO.java:315)
at org.ofbiz.core.entity.GenericDAO.storeAll(GenericDAO.java:347)
at org.ofbiz.core.entity.GenericHelperDAO.storeAll(GenericHelperDAO.java:195)
at org.ofbiz.core.entity.GenericDelegator.storeAll(GenericDelegator.java:1037)
at com.atlassian.jira.issue.managers.DefaultActionManager.createAction(DefaultActionManager.java:87)
at com.atlassian.jira.issue.managers.DefaultActionManager.createComment(DefaultActionManager.java:61)
at com.atlassian.jira.issue.managers.DefaultActionManager.createComment(DefaultActionManager.java:49)
at com.atlassian.jira.web.action.issue.AddComment.doExecute(AddComment.java:43)
Michael Phillimore-Brown
added a comment - Hi again,
Yes the problem did seem to be that by default Sybase will not allow nulls in any column. In Sybase 12 there is an option to allow nulls by default when creating the database tables. I selected this and now JIRA is 98% fine.
There is an issue adding comments, however. Using Tomcat you get an error after you've added a comment (stack trace below). The weird thing is the comment gets added anyway...
Using Orion you also get a stack trace starting with 'java.lang.IllegalArgumentException: [GenericDelegator.refresh] could not refresh value: [GenericEntity:Action] [body,asf] [issue,10012] [type,comment] [author,mbrown] [level,null] [created,2002-05-28 16:52:39.515] [id,10025] ' and the comment does not get saved.
It looks to me like the ofbiz stuff doesn't quite work with Sybase at the moment, which is a shame as it's so close.
Another issue seems to be that Sybase is case sensitive when it comes to columns and table names and for some reason some columns are created in upper case and some in lower case. Anyway I think we're going to have to stick with Oracle for now but I hope this helps potential Sybase users.
Regards,
Mike
javax.servlet.ServletException: System error while executing class com.atlassian.jira.web.action.issue.AddComment
Root Cause:
org.ofbiz.core.entity.GenericNotImplementedException: Java type com.sybase.jdbc2.tds.SybTimestamp not currently supported. Sorry.
at org.ofbiz.core.entity.GenericDAO.setValue(GenericDAO.java:1833)
at org.ofbiz.core.entity.GenericDAO.singleUpdate(GenericDAO.java:277)
at org.ofbiz.core.entity.GenericDAO.singleStore(GenericDAO.java:315)
at org.ofbiz.core.entity.GenericDAO.storeAll(GenericDAO.java:347)
at org.ofbiz.core.entity.GenericHelperDAO.storeAll(GenericHelperDAO.java:195)
at org.ofbiz.core.entity.GenericDelegator.storeAll(GenericDelegator.java:1037)
at com.atlassian.jira.issue.managers.DefaultActionManager.createAction(DefaultActionManager.java:87)
at com.atlassian.jira.issue.managers.DefaultActionManager.createComment(DefaultActionManager.java:61)
at com.atlassian.jira.issue.managers.DefaultActionManager.createComment(DefaultActionManager.java:49)
at com.atlassian.jira.web.action.issue.AddComment.doExecute(AddComment.java:43)
Michael Phillimore-Brown
added a comment - Hi Mike,
Thanks for the quick reply. Yes, the problem disappears and JIRA runs fine on Oracle. The only thing I could think of was if some user information is stored elsewhere and it was trying to tie up the user I set up in Oracle with the (empty) Sybase db. Another thing is that Sybase doesn't support Sequences, at least in the same way Oracle does.
I've e-mailed you with the DDL for the database - actually another thing I've just noticed is that all columns are NOT NULL (the default in Sybase). Thinking about it this seems a pretty likely candidate...
Any ideas would be much appreciated!
Regards,
Mike
Michael Phillimore-Brown
added a comment - Hi Mike,
Thanks for the quick reply. Yes, the problem disappears and JIRA runs fine on Oracle. The only thing I could think of was if some user information is stored elsewhere and it was trying to tie up the user I set up in Oracle with the (empty) Sybase db. Another thing is that Sybase doesn't support Sequences, at least in the same way Oracle does.
I've e-mailed you with the DDL for the database - actually another thing I've just noticed is that all columns are NOT NULL (the default in Sybase). Thinking about it this seems a pretty likely candidate...
Any ideas would be much appreciated!
Regards,
Mike Mike Cannon-Brookes
added a comment - Michael,
I'll try to take a look at this on Monday. What you've done seems to look fine to me, and the stack trace is in an awfully odd position.
Shows the source of the class in question - and line 166 doesn't seem to indicate anything to do with the DB at all.
If you switch to HSQL or Oracle, is the error still there - or does it disappear?
I'll try to think of some other debugging suggestions tomorrow - it's 3am here and I apologise for my largely inactive brain 
Cheers,
Mike
Mike Cannon-Brookes
added a comment - Michael,
I'll try to take a look at this on Monday. What you've done seems to look fine to me, and the stack trace is in an awfully odd position.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/opensymphony/osuser/src/com/opensymphony/module/user/provider/ofbiz/OFBizAbstractProvider.java?annotate=1.3
Shows the source of the class in question - and line 166 doesn't seem to indicate anything to do with the DB at all.
If you switch to HSQL or Oracle, is the error still there - or does it disappear?
I'll try to think of some other debugging suggestions tomorrow - it's 3am here and I apologise for my largely inactive brain
Cheers,
Mike 
I'm closing this due to Grant's inclusion of fieldtypes for sybase.
If this doesn't work - please let use know.
Cheers,
Scott