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/22 03:50:55 UTC
[jira] Created: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
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: Unassigned
Priority: Blocker
Project: Jetspeed 2
Components:
Other
Versions:
2.0-dev/cvs
Assignee:
Reporter: Ate Douma
Created: Wed, 21 Apr 2004 6:50 PM
Updated: Wed, 21 Apr 2004 6:50 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
[jira] Assigned: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB
Posted by ji...@apache.org.
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
[jira] Updated: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Ate Douma (mailto:ate@douma.nu)
Date: Tue, 27 Apr 2004 12:48 PM
Comment:
I've attached my build.properties as an example how I got Jetspeed running using Oracle9i.
I will also attach my related p6spy spy.properties file in a sec.
Changes:
Attachment changed to build.properties
---------------------------------------------------------------------
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:48 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
[jira] Updated: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Ate Douma (mailto:ate@douma.nu)
Date: Tue, 27 Apr 2004 12:50 PM
Comment:
Final attachment: my spy.properties related to the build.properties I've attached before.
Changes:
Attachment changed to spy.properties
---------------------------------------------------------------------
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:50 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
[jira] Updated: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Ate Douma (mailto:ate@douma.nu)
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Ate Douma
Created: Wed, 21 Apr 2004 6:52 PM
Body:
Sorry, I mixed up the problem numbers: there are 5.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-18?page=comments#action_35201
---------------------------------------------------------------------
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: Unassigned
Priority: Blocker
Project: Jetspeed 2
Components:
Other
Versions:
2.0-dev/cvs
Assignee:
Reporter: Ate Douma
Created: Wed, 21 Apr 2004 6:50 PM
Updated: Wed, 21 Apr 2004 6:52 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
[jira] Commented: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Ate Douma
Created: Thu, 29 Apr 2004 12:50 AM
Body:
David,
I just checked out a fresh HEAD version and run it through build and deploy on Oracle.
Except for the failing of the TestFileCache (JS2-19) which keeps bugging me (I forgot to apply my own patch initially), all went well.
So, I can confirm it working while using a clean setup with Oracle database.
I also noticed you added some maven.test.dest property settings so I tested components/jetspeed and components/prefs standalone as well. The components/jetspeed still breaks but component/prefs now works!
Finally, for using the build.properties.sample you checked in (good) there should be some documentation because it scope as defined in the root of J2 is only there. It should be put into a user HOME to get it working also for standalone subproject builds and tests.
But then, the GETTING-STARTED.html should be updated for (links to) howtos running on Oracle and MySql I think.
I will try to write the howto for Oracle this weekend and attach it to this issue when done. I don't have MySql running so maybe someone else can do that?
Probably these should not go in GETTING-STARTED.html anymore but in the xdocs? I don't have experience with that but will try to check it out (I need it for proper documentation of the Struts Portlet also). Any important pointers I might need for that would be very much appreciated.
Regards,
Ate
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-18?page=comments#action_35322
---------------------------------------------------------------------
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: Thu, 29 Apr 2004 12:50 AM
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
[jira] Updated: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Ate Douma (mailto:ate@douma.nu)
Date: Thu, 22 Apr 2004 10:37 AM
Comment:
Patch proposal fixing the "value to large for column" bugs (described in problem 3).
All three class_name field definitions which were less than 255 long I changed to size 255 (equal to the other class_name field sizes).
Changes:
Attachment changed to JS2-18-patch-registry-schema-1.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: Unassigned
Priority: Blocker
Project: Jetspeed 2
Components:
Other
Versions:
2.0-dev/cvs
Assignee:
Reporter: Ate Douma
Created: Wed, 21 Apr 2004 6:50 PM
Updated: Thu, 22 Apr 2004 10:37 AM
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
[jira] Commented: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: David Le Strat
Created: Wed, 28 Apr 2004 8:09 PM
Body:
Applied patch from Ate. Validated that it works with maven.rc1 and HSQL db.
Please validate that the applied patch provides Oracle support and close the issue.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-18?page=comments#action_35313
---------------------------------------------------------------------
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: Wed, 28 Apr 2004 8:09 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
[jira] Closed: (JS2-18) Cannot run J2 using Oracle due to problems with OBJ, Torque and dependencies on HSQLDB
Posted by ji...@apache.org.
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org