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 Ate Douma <at...@douma.nu> on 2004/04/22 12:52:03 UTC
[J2] Unable to use Oacle for J2 because of problems with OBJ, Torque
and HSQLDB dependencies
I've created Blocking issue JS2-18 last night after a long frustrated
day trying to get J2 ready to use Oracle as db.
In that issue I identified (at least) 5 major problems I like to ask
attention to.
Although JIRA is fine for issue tracking I think the mailing list is
more interactive to discuss these issues.
Therefore I created this mail as a wrapper for the several problems
which I will describe separately as reply to this mail.
I am very dependent on Oracle for running J2 as it is required for my
client. Furthermore, in our project we will start developing portlets
based on J2 any time now (I know its kind of early for that but we need
some result before the summer and hopefully our development will provide
lots of feedback to J2 to help it get out of the door sooner).
Regards, Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Unable to use Oacle for J2 because of problems with OBJ,
Torque and HSQLDB dependencies
Posted by Ate Douma <at...@douma.nu>.
David (Le Strat),
Thanks for applying the patch!
Regards,
Ate
Ate Douma wrote:
> Hello all,
>
> I've finally got Jetspeed working using Oracle (Oracle9i).
> Just before this weekend David Sean Taylor has already committed a few
> important fixed and the last big problem was the dependency on Hsqldb
> which was spread throughout the codebase.
>
> I've found a general solution for which I have created a patch. I
> attached it, including a long comment and my build.properties, to JS2-18.
>
> I would kindly ask committers (David or someone else) to look into this
> patch and evaluate if it is anywhere feasible to apply.
>
> If it is feasible then please commit the patch so I can use Jetspeed
> with Oracle from a fresh cvs HEAD retrieval (which I do often :-)).
>
> Regards,
>
> Ate
>
> Ate Douma wrote:
>
>> I've created Blocking issue JS2-18 last night after a long frustrated
>> day trying to get J2 ready to use Oracle as db.
>>
>> In that issue I identified (at least) 5 major problems I like to ask
>> attention to.
>>
>> Although JIRA is fine for issue tracking I think the mailing list is
>> more interactive to discuss these issues.
>> Therefore I created this mail as a wrapper for the several problems
>> which I will describe separately as reply to this mail.
>>
>> I am very dependent on Oracle for running J2 as it is required for my
>> client. Furthermore, in our project we will start developing portlets
>> based on J2 any time now (I know its kind of early for that but we
>> need some result before the summer and hopefully our development will
>> provide lots of feedback to J2 to help it get out of the door sooner).
>>
>> Regards, Ate
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>>
>> .
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Unable to use Oacle for J2 because of problems with OBJ,
Torque and HSQLDB dependencies
Posted by Ate Douma <at...@douma.nu>.
Hello all,
I've finally got Jetspeed working using Oracle (Oracle9i).
Just before this weekend David Sean Taylor has already committed a few
important fixed and the last big problem was the dependency on Hsqldb
which was spread throughout the codebase.
I've found a general solution for which I have created a patch. I
attached it, including a long comment and my build.properties, to JS2-18.
I would kindly ask committers (David or someone else) to look into this
patch and evaluate if it is anywhere feasible to apply.
If it is feasible then please commit the patch so I can use Jetspeed
with Oracle from a fresh cvs HEAD retrieval (which I do often :-)).
Regards,
Ate
Ate Douma wrote:
> I've created Blocking issue JS2-18 last night after a long frustrated
> day trying to get J2 ready to use Oracle as db.
>
> In that issue I identified (at least) 5 major problems I like to ask
> attention to.
>
> Although JIRA is fine for issue tracking I think the mailing list is
> more interactive to discuss these issues.
> Therefore I created this mail as a wrapper for the several problems
> which I will describe separately as reply to this mail.
>
> I am very dependent on Oracle for running J2 as it is required for my
> client. Furthermore, in our project we will start developing portlets
> based on J2 any time now (I know its kind of early for that but we need
> some result before the summer and hopefully our development will provide
> lots of feedback to J2 to help it get out of the door sooner).
>
> Regards, Ate
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Unable to use Oacle for J2 because of problems with OBJ,
Torque and HSQLDB dependencies: Torque sql generation
Posted by Ate Douma <at...@douma.nu>.
The abstract schema definition file phase3ojb-schema.xml defines for
table OJB_DMAP_ENTRIES two columns of type BINARY. Torque generates for
Oracle LONG RAW columns for those. Which is NOT allowed in Oracle. Only
one LONG RAW (which has a 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 looks to come from OJB itself!
More general, what does this schema definition do? And is the
OJB_DMAP_ENTRIES table needed? It probably is required for OJB but is it
dependent on how OJB is used or just always required (that would
wonder me because then OBJ usage for Oracle would be impossible as such).
Another problem with Torque is the sql generated from
security-schema.xml. It defines two foreign key constraints whose name
is longer than 30 characters which is the limit for Oracle. As I don't
have any experience with Torque I don't know if and then how this
restriction can be configured. I would think some sort of Oracle
specific implementation class should handle those but I couldn't find
out where or how to enforce Torque to use it.
I temporarily handled these issues by patching the generated sql by
hand. Which is not a good idea of course. The first time I did run
allBuild again I lost my changes as to be expected. So I hacked the
maven allBuild goal to not regenerate the sql every time allBuild is
run. Which I think could be better overall. How often will the schema
change anyhow. Only then, and for a first time build that would be
required. I suggest adding a instruction in GETTING-STARTED.html for the
first time users to manually first generate the sql before doing an
allBuild just like they have to do a db.recreate before a fullDeployment.
One last question of more informative nature. I saw Torque generate a
sqldb.map file. What is that supposed to do?
Regards,
Ate
Ate Douma wrote:
> I've created Blocking issue JS2-18 last night after a long frustrated
> day trying to get J2 ready to use Oracle as db.
>
> In that issue I identified (at least) 5 major problems I like to ask
> attention to.
>
> Although JIRA is fine for issue tracking I think the mailing list is
> more interactive to discuss these issues.
> Therefore I created this mail as a wrapper for the several problems
> which I will describe separately as reply to this mail.
>
> I am very dependent on Oracle for running J2 as it is required for my
> client. Furthermore, in our project we will start developing portlets
> based on J2 any time now (I know its kind of early for that but we need
> some result before the summer and hopefully our development will provide
> lots of feedback to J2 to help it get out of the door sooner).
>
> Regards, Ate
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J1] Tagging Release 1.5
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Apr 22, 2004, at 12:44 PM, David Sean Taylor wrote:
> I started the 1.5 release and will be tagging the CVS shortly if all
> goes well.
> Could we please hold off on commits until I've completed the tag,
> thanks!
>
CVS tag completed
JETSPEED-RELEASE-1-5
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[J1] Tagging Release 1.5
Posted by David Sean Taylor <da...@bluesunrise.com>.
I started the 1.5 release and will be tagging the CVS shortly if all
goes well.
Could we please hold off on commits until I've completed the tag,
thanks!
(this does not apply to the J2 CVS)
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Unable to use Oacle for J2 because of problems with OBJ,
Torque and HSQLDB dependencies: HSQLDB reliability
Posted by Ate Douma <at...@douma.nu>.
I've just posted a patch file to issue JS2-18 for the "value to large
for column" errors caused by the class_name field sizes being to small
in registry-schema.xml. Three references I changed the size to 255,
equal to the size of all other class_name field definitions.
Regards,
Ate
Ate Douma wrote:
> After I got an working schema in Oracle I could start the allBuild.
> But, alas, no luck.
> After a lengthy period of debugging and even wrapping the Oracle jdbc
> driver in a patched version of P6Spy (great tool that is, it just didn't
> even log enough) I found two problems in the schema definitions which
> using HSQLDB won't be noticed.
>
> First of all the size of VARCHAR fields. It turned out that
> PARAMETER.CLASS_NAME and PORTLET_PREFERENCE.CLASS_NAME are scaled way to
> small (30 and 50 characters). I don't know the formal maximum length of
> a class name but I would suggest defining 256 to be on the save side.
> For HSQLDB this isn't an issue at all because although you may define
> size restrictions on VARCHAR columns in practice these are simply
> ignored and any size is allowed.
>
> Secondly, lots of the registry tables have an ID reference to
> JetspeedObjectID (which is internally just an int). In the schema
> definition these are just referenced as an INTEGER and OJB therefore
> will use (Prepared)Statement.setObject(index, anJetspeedObjectID,
> sql.Types.INTEGER). The Oracle jdbc driver chokes on that of course and
> throws correctly an ClassCastException. Not so with HSQLDB though. That
> seems handle this by new Integer(anJetspeedObjectID.toString()) or
> something like it.
>
> The problem with using HSQLDB is thus that it isn't really a reliably
> database for testing if the schema definition is correct. Only a *real*
> rdbms will enforce the specifications.
> Of course, HSQLDB is just fine as lightweight database for development
> but for schema validation you can't depend on it.
> Switching J2 development to use another, more reliable database isn't
> really practical because almost any other database requires much more
> setup and maintenance but still this the schema validation should be
> checked one way or the other (maybe McKoi db is more strict and as
> another lightweight db could be an option but it has a GPL license so
> that probably prohibits it for Apache usage).
>
> Regards,
>
> Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Unable to use Oacle for J2 because of problems with OBJ,
Torque and HSQLDB dependencies: HSQLDB reliability
Posted by Ate Douma <at...@douma.nu>.
After I got an working schema in Oracle I could start the allBuild.
But, alas, no luck.
After a lengthy period of debugging and even wrapping the Oracle jdbc
driver in a patched version of P6Spy (great tool that is, it just didn't
even log enough) I found two problems in the schema definitions which
using HSQLDB won't be noticed.
First of all the size of VARCHAR fields. It turned out that
PARAMETER.CLASS_NAME and PORTLET_PREFERENCE.CLASS_NAME are scaled way to
small (30 and 50 characters). I don't know the formal maximum length of
a class name but I would suggest defining 256 to be on the save side.
For HSQLDB this isn't an issue at all because although you may define
size restrictions on VARCHAR columns in practice these are simply
ignored and any size is allowed.
Secondly, lots of the registry tables have an ID reference to
JetspeedObjectID (which is internally just an int). In the schema
definition these are just referenced as an INTEGER and OJB therefore
will use (Prepared)Statement.setObject(index, anJetspeedObjectID,
sql.Types.INTEGER). The Oracle jdbc driver chokes on that of course and
throws correctly an ClassCastException. Not so with HSQLDB though. That
seems handle this by new Integer(anJetspeedObjectID.toString()) or
something like it.
The problem with using HSQLDB is thus that it isn't really a reliably
database for testing if the schema definition is correct. Only a *real*
rdbms will enforce the specifications.
Of course, HSQLDB is just fine as lightweight database for development
but for schema validation you can't depend on it.
Switching J2 development to use another, more reliable database isn't
really practical because almost any other database requires much more
setup and maintenance but still this the schema validation should be
checked one way or the other (maybe McKoi db is more strict and as
another lightweight db could be an option but it has a GPL license so
that probably prohibits it for Apache usage).
Regards,
Ate
Ate Douma wrote:
> I've created Blocking issue JS2-18 last night after a long frustrated
> day trying to get J2 ready to use Oracle as db.
>
> In that issue I identified (at least) 5 major problems I like to ask
> attention to.
>
> Although JIRA is fine for issue tracking I think the mailing list is
> more interactive to discuss these issues.
> Therefore I created this mail as a wrapper for the several problems
> which I will describe separately as reply to this mail.
>
> I am very dependent on Oracle for running J2 as it is required for my
> client. Furthermore, in our project we will start developing portlets
> based on J2 any time now (I know its kind of early for that but we need
> some result before the summer and hopefully our development will provide
> lots of feedback to J2 to help it get out of the door sooner).
>
> Regards, Ate
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Unable to use Oacle for J2 because of problems with OBJ,
Torque and HSQLDB dependencies: OJB FieldConversion
Posted by Ate Douma <at...@douma.nu>.
Sorry, forgot to attach the test case result
Ate Douma wrote:
> Related to my previous mail (HSQLDB reliability) is the mapping of
> JetspeedObjectID to an INTEGER field in OJB repository_registry.xml.
>
> After I found out about the problem of the mapping I searched for a way
> to let OJB do an conversion.
> The FieldConversion interface is available for that and it turned out
> that an implementation for JetspeedObjectID was already written, just
> not used yet (or anymore).
>
> After looking up the first reference to a JetspeedObjectID I found in
> that for the PortletApplicationDefinitionImpl.id mapping the conversion
> attribute referencing the ObjectIDtoLongFieldConversion implementation
> of FieldConversion was commented out. So I enabled it again.
> Wrong. Now I got an IllegalArgumentException thrown.
> I've attached the test case result which shown the error and stack trace
> for it.
> Note: I did put logging messages in the ObjectIDtoLongFieldConversion
> sqlToJava and javaToSql methods to see what was passed in and you'll
> notice one of these (sqlToJava) in the test case results.
>
> What is going wrong here I really don't know as this probably requires
> detailed OJB knowledge which I don't have.
> I have a bad feeling though it could be related to the fact that this id
> field has autoincrement defined and from the error log you can see the
> problem seems to come from code handling that. If thats the cause of it
> then probably OJB doesn't support FieldConversion for autoincrement
> fields which would be a real bummer as it really is required here.
>
> Anyway, I leave this to the OJB expects to look into it. My current
> expertise ends here. I saw Brian McCallister joined the club so maybe he
> can shine some light on this?
>
> Well, this is the last problem for now I have to get Oracle usage.
> Hopefully once these are resolved no other will pop up (note I didn't
> got passed the allBuild yet, running J2 is still way off as such).
>
> I am more than willing to test any workaround or fix on oracle so as
> soon as anyone got something to test just let me know.
>
> Regards,
>
> Ate
>
>
> Ate Douma wrote:
>
>> I've created Blocking issue JS2-18 last night after a long frustrated
>> day trying to get J2 ready to use Oracle as db.
>>
>> In that issue I identified (at least) 5 major problems I like to ask
>> attention to.
>>
>> Although JIRA is fine for issue tracking I think the mailing list is
>> more interactive to discuss these issues.
>> Therefore I created this mail as a wrapper for the several problems
>> which I will describe separately as reply to this mail.
>>
>> I am very dependent on Oracle for running J2 as it is required for my
>> client. Furthermore, in our project we will start developing portlets
>> based on J2 any time now (I know its kind of early for that but we
>> need some result before the summer and hopefully our development will
>> provide lots of feedback to J2 to help it get out of the door sooner).
>>
>> Regards, Ate
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>>
>> .
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
>
Re: [J2] Unable to use Oacle for J2 because of problems with OBJ,
Torque and HSQLDB dependencies: OJB FieldConversion
Posted by Ate Douma <at...@douma.nu>.
Related to my previous mail (HSQLDB reliability) is the mapping of
JetspeedObjectID to an INTEGER field in OJB repository_registry.xml.
After I found out about the problem of the mapping I searched for a way
to let OJB do an conversion.
The FieldConversion interface is available for that and it turned out
that an implementation for JetspeedObjectID was already written, just
not used yet (or anymore).
After looking up the first reference to a JetspeedObjectID I found in
that for the PortletApplicationDefinitionImpl.id mapping the conversion
attribute referencing the ObjectIDtoLongFieldConversion implementation
of FieldConversion was commented out. So I enabled it again.
Wrong. Now I got an IllegalArgumentException thrown.
I've attached the test case result which shown the error and stack trace
for it.
Note: I did put logging messages in the ObjectIDtoLongFieldConversion
sqlToJava and javaToSql methods to see what was passed in and you'll
notice one of these (sqlToJava) in the test case results.
What is going wrong here I really don't know as this probably requires
detailed OJB knowledge which I don't have.
I have a bad feeling though it could be related to the fact that this id
field has autoincrement defined and from the error log you can see the
problem seems to come from code handling that. If thats the cause of it
then probably OJB doesn't support FieldConversion for autoincrement
fields which would be a real bummer as it really is required here.
Anyway, I leave this to the OJB expects to look into it. My current
expertise ends here. I saw Brian McCallister joined the club so maybe he
can shine some light on this?
Well, this is the last problem for now I have to get Oracle usage.
Hopefully once these are resolved no other will pop up (note I didn't
got passed the allBuild yet, running J2 is still way off as such).
I am more than willing to test any workaround or fix on oracle so as
soon as anyone got something to test just let me know.
Regards,
Ate
Ate Douma wrote:
> I've created Blocking issue JS2-18 last night after a long frustrated
> day trying to get J2 ready to use Oracle as db.
>
> In that issue I identified (at least) 5 major problems I like to ask
> attention to.
>
> Although JIRA is fine for issue tracking I think the mailing list is
> more interactive to discuss these issues.
> Therefore I created this mail as a wrapper for the several problems
> which I will describe separately as reply to this mail.
>
> I am very dependent on Oracle for running J2 as it is required for my
> client. Furthermore, in our project we will start developing portlets
> based on J2 any time now (I know its kind of early for that but we need
> some result before the summer and hopefully our development will provide
> lots of feedback to J2 to help it get out of the door sooner).
>
> Regards, Ate
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Unable to use Oacle for J2 because of problems with OBJ,
Torque and HSQLDB dependencies: hardcoded HSQLDB usage
Posted by Ate Douma <at...@douma.nu>.
The first problem I encountered was the usage of HSQLDB connection
parameter definitions all over the place.
Most sub project have these parameters defined all over again in their
own project.properties.
My standing on this is that there should be only one place
(J2/project.properties) defining those. Because the subproject all
inherit from the root project.xml this should be no problem.
I did remove all the definitions from the sub projects and could still
run allBuild (still with HSQLDB) without any problem. I didn't check
standalone testing for each subproject though so there may still be some
issues.
Another point where the a HSQLDB dependency is hard coded is in the
repository_database.xml for the platform attribute. That file is further
more also defined on multiple locations so its not clear to me which
should be considered the master file. Anyway, the platform attribute
really should be derived from J2/project.properties I think.
Regards,
Ate
Ate Douma wrote:
> I've created Blocking issue JS2-18 last night after a long frustrated
> day trying to get J2 ready to use Oracle as db.
>
> In that issue I identified (at least) 5 major problems I like to ask
> attention to.
>
> Although JIRA is fine for issue tracking I think the mailing list is
> more interactive to discuss these issues.
> Therefore I created this mail as a wrapper for the several problems
> which I will describe separately as reply to this mail.
>
> I am very dependent on Oracle for running J2 as it is required for my
> client. Furthermore, in our project we will start developing portlets
> based on J2 any time now (I know its kind of early for that but we need
> some result before the summer and hopefully our development will provide
> lots of feedback to J2 to help it get out of the door sooner).
>
> Regards, Ate
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org