portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject [jira] Closed: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB
Date Wed, 05 May 2004 21:18:56 GMT

   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:

Here is an overview of the issue:
        Key: JS2-18
    Summary: Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies
       Type: Bug

     Status: Closed
   Priority: Blocker
 Resolution: FIXED

    Project: Jetspeed 2

   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

I've been trying real hard for almost a day now to get J2 running with Oracle as db instead

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

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.
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
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?



This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message