The following issue has been updated:
Updater: Ate Douma (mailto:[EMAIL PROTECTED])
Date: Tue, 27 Apr 2004 12:46 PM
Comment:
I've attached JS2-18-patch-db-build-properties.txt.
This is one big large patch to many (not all) maven.xml, project.properties and some
project.xml files.
It abstracts the dependency on hsqldb by allowing overrides in once own
HOME/build.properties (.e.g to be able to use Oracle or whatever other db).
To start out with: if you use it with the default Hsqldb (no db build properties in
your build.properties) it works just like before (tested but read the last few lines
of this comment)!
I've split the database properties in two: test properties and production properties.
Now you can define a debug jdbc driver (like p6Spy, more about that one below) for
test build and a formal jdbc driver for production. Different database for test and
production are likewise possible.
Furthermore, I've also ensured all of them have the prefix org.apache.jetspeed. (I
hate it when I have to define properties in my HOME/build.properties without a proper
namespace).
To allow the usage of the open source p6Spy jdbc driver
wrapper/logger I had to add its p6.home system property (with which it locates its
spy.properties) to the maven.junit.systemproperties definitions. If will do no harm if
you're not using p6Spy but without you can't use it.
The different OJB repository_database.xml definitions which contained a hardcoded
platform="Hsqldb" are now filtered before used to allow a different platform setting
from your build.properties.
Finally, the portal jetspeed.xml is also filtered so it will be deployed with the
correct production database properties.
If you're using a different database, you'll need other drivers. To allow the usage of
your own modifiy the jdbc.drivers.path property in your build.properties. It is an Ant
path property so you can put more than one driver in it.
There is NO need to define additional dependencies for these drivers: the
jdbc.driver.path is dynamically merged with the maven.dependency.classpath (when
needed).
With the paches already committed this one will allow full Oracle usage so committing
this one should fix this bug.
Using Oracle or some other database now just requires setting the right properties in
your HOME/build.properties.
Don't forget to include your driver jars in the Tomcat/shared/lib folder as those
won't be automatically put in the jetspeed.war (as the hsqldb.jar is).
A last small problem left is the fact that the sql table create scripts start out with
trying to the delete a previous version of the table. Which fails of course if it is
the first time you ever run it. So (at least for Oracle), the first time you will have
to modify these scripts and remove the drop statements.
It would be nice if someone could fix this also.
I will attach as an example my build.properties after this one. Because it used p6spy
for test builds I will also attach the related spy.properties I use.
For anyone interested in p6spy, find it here: http://www.p6spy.com
Committers, please review this patch carefully. I did test the patch myself after
getting a fresh cvs head and it does work (both with Oracle and the default Hsqldb).
I also tested each sub project individually if they still worked after the patch. Only
the components/jetspeed and components/prefs failed but then these already failed
(with the same cause) before the patch. Someone should look into those problems...
As a final remark: I use maven 1.0rc2 and didn't check if it also works with whichever
version before that. All the maven/jelly features I used though were available before.
I hope this patch (or at least something with equal effect) can be applied soon and
before other changes checked in on the related files (which could lead to a
redefinition of the patch).
Regards,
Ate
Changes:
Attachment changed to JS2-18-patch-db-build-properties.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/JS2-18?page=history
---------------------------------------------------------------------
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: Tue, 27 Apr 2004 12:46 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]
