Message:
The following issue has been closed.
Resolver: David Sean Taylor
Date: Wed, 5 May 2004 2:18 PM
Oracle is now building, testing, deploying and running successfully from the CVS head.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-18
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JS2-18
Summary: Cannot run J2 using Oracle due to problems with OBJ, Torque and
dependencies on HSQLDB
Type: Bug
Status: Closed
Priority: Blocker
Resolution: FIXED
Project: Jetspeed 2
Components:
Other
Versions:
2.0-dev/cvs
Assignee: David Sean Taylor
Reporter: Ate Douma
Created: Wed, 21 Apr 2004 6:50 PM
Updated: Wed, 5 May 2004 2:18 PM
Environment: WindowsXP, J2SE1.4.2_03, Tomcat 4.1.29, Oracle9i 9.2.0.1
Description:
I've been trying real hard for almost a day now to get J2 running with Oracle as db
instead of HSQLDB.
There are plenty of problems which I will try to recapture here:
1) HSQLDB configuration is spread out all over the place. To get the tests running
using the Oracle db I first updated J2/project.properties. But, it turned out that
almost all sub projects have again HSQLDB properties set in their project.properties.
I did remove all off those and then, at least by using J2/maven allBuild those sub
projects did use my Oracle connection parameters.
Of course, this breaks standalone building/testing of those sub projects so there
should be some smarter way to be able to handle this but I have not thought of
something (I haven't that much experience with maven).
2) phase3ojb-schema.xml defines for table OJB_DMAP_ENTRIES two columns of type BINARY.
Torque generated for Oracle LONG RAW columns for those. Which is NOT allowed. Only one
LONG RAW (max size 2 GIGA BYTES!) column per table is allowed in Oracle.
I have no idea how this is ever supposed to work for Oracle as this schema definition
comes from OJB itself!
To get things going I modified the generated sql myself by changing these columns to
RAW(2000). To be able to rerun allBuild without losing my changes I had to remove the
attainGoal db.scripts.gen from it. Could it be an idea to leave this out and let the
user do it (like the required db.recreate before portlal/fullDeployment)?
4) Another problem with the sql scripts was thas foreign key names were generated
longer than 30 characters which is also not allowed with Oracle:
SECURITY_PRINCIPAL_PERMISSION_FK_1 and SECURITY_PRINCIPAL_PERMISSION_FK_2. This is
probably a Torque problem. I have no experience with Torque so I just shortened the
names to be able to continue.
3) Now, I could start the tests. Buggar, failures all over the place.
The first once were due to "value to large for column" errors. It turned out that the
PARAMETER.CLASS_NAME has a size of 30 and PORTLET_PREFERENCE.CLASS_NAME a size of 50.
Both are way too small.
I'm not sure what the maximum lenght of a class name is, but it would probably be
better to set those to 250 or something.
The real problem though is the usage of HSQLDB I think. It just simply ignores size
specifications on VARCHAR columns! These type of problems (and below I will describe
another even more serious type) thus can never be tested out using HSQLDB.
4) The next set of errors were due to a ClassCastException from the Oracle driver on
PreparedStatement.setObject(index, Object, type) calls. That one really took a long
time to find out for which table and which column what type of Object was wrongly
thrown in (I resorted to hacking P6Spy to get it to log the setObject method and wrap
it around the Oracle driver).
The culprit was JetspeedObjectID which was passed in as sql.Type.INTEGER.
After first delving into the J2 usage of it I went looking for some conversion
possibility in OJB. Turned out there is such a feature AND the FieldConversion class
for JetspeedObjectID was already written
(o.a.j.util.ojb.ObjectIDtoLongFieldConversion) only not used.
Alright.
So I modified repository_registry.xml. The first (and only) field I tried to correct
was PORTLET_APPLICATION.APPLICATION_ID because it already had the conversion attribute
correctly defined, only commented out! So I enabled the attribute and did run allBuild
again.
No luck: IllegalArgumentException from
sun.reflect.UnsafeIntegerFieldAccessorImpl.set().
Somewhat down the error log (from the TestPortletEntityAccessComponent) OBJ gives the
error: Error while trying to autoincrement field class
org.apache.jetspeed.om.portlet.impl.PortletApplicationDefinitionImpl#id. Indeed, the
field has autoincrement=true defined.
My guess is OBJ doesn't support (yet) FieldConversion for either primary keys or
autoincrement field.
Anyway, I have given up.
Again, the real problem seems to be the usage of HSQLDB which doesn't mind at all when
an complete different object type is put into an INTEGER field. Right.
So, as far as I can see, Oracle support is still far off. which is a real Blocker for
me and my client. I HAVE to have J2 running on Oracle yesterday. I didn't think much
of it till today because the O/R mapping was done with OBJ and that one is is in use
already long enough so I guessed switching to Oracle wouldn't be a problem.
Not so.
I realize I am a little pissed off after a whole day fighting bugs and getting nowhere
and it probably coming through. Then I want to apologise for that because I'm actually
angry at myself not thinking ahead.
Still, I really must have this resolved ASAP because development based on J2 will
start real soon now in my project.
Please, can anyone of the J2 team give an indication if and when these problems, and
any other which prevents the use of Oracle as database, will get resolved?
Regards,
Ate
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
