You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by ji...@apache.org on 2004/04/23 21:20:53 UTC

[jira] Assigned: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB

Message:

   The following issue has been re-assigned.

   Assignee: David Sean Taylor (mailto:taylor@apache.org)
---------------------------------------------------------------------
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: Open
   Priority: Blocker

    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: Fri, 23 Apr 2004 12:20 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org