You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Laurie Harper <zo...@holoweb.net> on 2002/12/07 04:41:18 UTC
TDK 2.2 glitches
Noticing that TDK 2.2 was in the release directory I decided to give it
a try. Turns out there's a few problems the tdk-howto doesn't mention so
I thought I'd document what I had to do over and above what the howto
says under Creating your first application:
Step 3. Run 'ant': gives error 'tdk.home' not set. It should default to
the current directory.
Step 4. Database settings in build.properties are defined in terms of
themselves or properties that are not otherwise defined (e.g.
${target.database}). There's no doc'n in the build.props or HOWTO as to
what these should look like! In particular:
* It's not clear that ${database} should be set to the target database
engine; I originally set it to the name of my database, which generated
errors about missing templates during generation. The legal values
should be listed and, ideally, the value should be validated so a clear
error message can be supplied.
* I can't figure out what ${database.name} should be set to, but it
doesn't seem to be used anywhere anyhow... (unless it's getting
transmogrified into ${torque.database.name} somewhere? I set it to
'newapp' which seems to have worked.
* What's the difference between createDatabaseUrl, buildDatabaseUrl and
databaseUrl? I've just set them all to the same thing for now which
seems to have worked (at least mostly, see below).
Step 4. Run 'ant init': gives an error that
tdk-2.2/webapps/newapp/WEB-INF/build/${tdk.home} does not exist! It
looks like ${tdk.home} is expected to be defined as something other than
the TDK installation directory?? However, looking at buld.xml it clearly
should be the installation directory so that's what I set it to. It
should default to ../../../..
That was enough to get things going, with the following caveats:
create-db.sql is generated with drop/create pairs for databases named
'third', 'second' and 'default' in addition to 'newapp'; the create-db
task fails with the error 'java.sql.SQLException: FATAL 1: Database
"newapp" does not exist in the system catalog.' (using postgreql). I had
to create the database by hand. This gave me a bunch of errors dropping
the spurious databases and a complaint about dropping the currently open
database (I assume I should have used something different for the
createDatabaseUrl property, but what?)
Finally, insert-sql issues lots of errors trying to drop tables which
don't exist; why try and drop tables in a database that's just been
created and is thus geranteed not to contain them...?
But now the generated app is working! Now for the fun part: using that
as a basis to update my 2.1 based stuff to 2.2... Wish me luck ;-)
L.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TDK 2.2 glitches
Posted by Alex McLintock <al...@OWAL.co.uk>.
At 22:14 09/12/02, you wrote:
>At 19:41 09/12/02, you wrote:
>>Rodney Schneider wrote:
>>
>>>The build.properties file that comes with the TDK should be documented
>>>thoroughly. Each property should be explained. Patches are always
>>>welcome :)
>
>
>
>Not quite a patch but here is some text which I seem to have from an old TDK
>I would have assumed that this would be in my TDK 2.2 generated
>build.properties, but it isn't.
>I can't guarantee what is still relevant in tdk 2.2
>
>This was reasonably straight forward, so I don't see why the helpful
>comments were removed....
Answering my own posting here..... It looks like the explanation of those
settings got moved here
/blah blah blah/tdk-2.2-b1/turbine/tdk/share/conf/torque/build.properties
and possibly then to here....
/tdk/ancillary/torque/src/conf/build.properties
But I don't understand why the explanation of the database settings is in
the torque directories....
Alex
Openweb Analysts Ltd, London.
Software For Complex Websites http://www.OWAL.co.uk/
Open Source Software Companies please register here
http://www.OWAL.co.uk/oss_support/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TDK 2.2 glitches
Posted by Alex McLintock <al...@OWAL.co.uk>.
At 19:41 09/12/02, you wrote:
>Rodney Schneider wrote:
>
>>The build.properties file that comes with the TDK should be documented
>>thoroughly. Each property should be explained. Patches are always
>>welcome :)
Not quite a patch but here is some text which I seem to have from an old TDK
I would have assumed that this would be in my TDK 2.2 generated
build.properties, but it isn't.
I can't guarantee what is still relevant in tdk 2.2
This was reasonably straight forward, so I don't see why the helpful
comments were removed....
# -------------------------------------------------------------------
#
# P R O J E C T P R O P E R T I E S
#
# -------------------------------------------------------------------
# These are the properties for your Turbine project. The properties
# in this file will override properties set anywhere else.
# -------------------------------------------------------------------
project=newapp
version=0.1
build.dest=../classes
src.dir=../src/java
conf.dir=../conf
master.conf.dir=../../../../share/conf
debug=on
optimize=off
deprecation=on
# -------------------------------------------------------------------
#
# T A R G E T D A T A B A S E
#
# -------------------------------------------------------------------
# This is the target database, only considered when generating
# the SQL for your Turbine project. Your possible choices are
#
# db2
# hypersonic
# mysql
# oracle,
# postgresql
#
# Default: none
# -------------------------------------------------------------------
database=mysql
#database.manual.creation = true
# -------------------------------------------------------------------
#
# O B J E C T M O D E L I N F O R M A T I O N
#
# -------------------------------------------------------------------
# These settings will allow you to customize the way your
# Peer-based object model is created.
# -------------------------------------------------------------------
extend=TurbineMapBuilder
mapname=TurbineMap
suffix=MapBuilder
targetPackage=org.mycompany.newapp.om
addSaveMethod=true
addGetByNameMethod=false
complexObjectModel=true
basePrefix=Base
# -------------------------------------------------------------------
#
# D A T A B A S E S E T T I N G S
#
# -------------------------------------------------------------------
# JDBC connection settings. This is used by the JDBCToXML task that
# will create an XML database schema from JDBC metadata. These
# settings are also used by the SQL Ant task to initialize your
# Turbine system with the generated SQL.
# -------------------------------------------------------------------
#--------------------------------------------------------------------
# HSQL use
# FULLPATH = full path to where you want the database
# Note: either torque or HSQL is really touchy about extra spaces
# or other stuff after each line below.
#--------------------------------------------------------------------
#databaseUrl=jdbc:HypersonicSQL:FULLPATH/newapp
#databaseDriver=org.hsql.jdbcDriver
#databaseUser=sa
#databasePassword=
databaseUrl = jdbc:mysql://127.0.0.1/newapp
databaseDriver = org.gjt.mm.mysql.Driver
databaseUser = root
databasePassword =
databaseHost = 127.0.0.1
# -------------------------------------------------------------------
# You should NOT have to edit anything below here.
# -------------------------------------------------------------------
# -------------------------------------------------------------------
#
# T E M P L A T E P A T H
#
# -------------------------------------------------------------------
templatePath = bin/torque/templates
# -------------------------------------------------------------------
#
# C O N T R O L T E M P L A T E S
#
# -------------------------------------------------------------------
SQLControlTemplate = sql/base/Control.vm
OMControlTemplate = om/Control.vm
idTableControlTemplate = sql/id-table/Control.vm
securityControlTemplate = sql/security/Control.vm
# -------------------------------------------------------------------
#
# O U T P U T D I R E C T O R Y
#
# -------------------------------------------------------------------
# The two properties are identical but they are like this for
# a reason. They are for testing the TDK, the reason they
# are duplicated is due to a bug in Ant with the <exec> task.
# -------------------------------------------------------------------
outputDirectory = ../src
fullPathOutputDirectory = ../src
# -------------------------------------------------------------------
#
# S C H E M A D I R E C T O R Y
#
# -------------------------------------------------------------------
schemaDirectory = ../conf
PS - sorry that my last message basically repeated the OP in this thread.
Alex
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TDK 2.2 glitches
Posted by Rodney Schneider <ro...@actf.com.au>.
On Sat, 7 Dec 2002 14:41, you wrote:
> Step 4. Database settings in build.properties are defined in terms of
> themselves or properties that are not otherwise defined (e.g.
> ${target.database}). There's no doc'n in the build.props or HOWTO as
> to what these should look like! In particular:
The build.properties file that comes with the TDK should be documented
thoroughly. Each property should be explained. Patches are always
welcome :)
> * It's not clear that ${database} should be set to the target
> database engine; I originally set it to the name of my database,
> which generated errors about missing templates during generation. The
> legal values should be listed and, ideally, the value should be
> validated so a clear error message can be supplied.
>
> * I can't figure out what ${database.name} should be set to, but it
> doesn't seem to be used anywhere anyhow... (unless it's getting
> transmogrified into ${torque.database.name} somewhere? I set it to
> 'newapp' which seems to have worked.
>
> * What's the difference between createDatabaseUrl, buildDatabaseUrl
> and databaseUrl? I've just set them all to the same thing for now
> which seems to have worked (at least mostly, see below).
You got the above settings right... see the Torque documentation for a
better explanation of what they all mean:
http://jakarta.apache.org/turbine/torque/properties-reference.html
They all get transmogrified during the build process. You can see how
this is done in the default.properties file inside the Torque jar.
> But now the generated app is working! Now for the fun part: using
> that as a basis to update my 2.1 based stuff to 2.2... Wish me luck
> ;-)
If you could document what you do as you go it would be much
appreciated. Quinton has documented the migration process a bit here:
http://archives.apache.org/eyebrowse/ReadMsg?listName=turbine-user@jakarta.apache.org&msgNo=12729
Between all of us we should be able to come up with a pretty good
Migration Howto.
Regards,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: intake and turbine 2 issues (was Re: TDK 2.2 glitches)
Posted by Laurie Harper <zo...@holoweb.net>.
Rodney Schneider wrote:
> Just for interest sake, what debugger are you using?
I'm using Intelli/J IDEA's built in debugger right now.
> I think the names must be javabean compliant for the reflection to
> work, so I am pretty sure they need to be munged...
For JavaBeans, properties are generally considered to be lower case; the
accessors are then upper-cased. So the property name (which is what the
values in intake.xml map to) would be 'name' not 'Name'. But it depends
on who's introspection semantics you're using ;-) You could always munge
at the point the reflection is performed so that the munging isn't
visible to the user when referencing properties.
> NestedException :)
Right, I knew it was something like that :)
> Yeah, that is what the TurbineException class in the Turbine 3
> repository does, and I am pretty sure it will make it into the Turbine
> 2.x repository eventually.
Of course the danger of nestable exceptions is that they end up used as
crutches to avoid doing real error handling and recovery... ;-)
L.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: intake and turbine 2 issues (was Re: TDK 2.2 glitches)
Posted by Rodney Schneider <ro...@actf.com.au>.
On Tue, 10 Dec 2002 17:05, you wrote:
> Rodney Schneider wrote:
> > Would it be possible for you to either supply a patch or at least
> > log an issue in Scarab for this problem?
>
> I can certainly file bug reports. Posting patches will need me to get
> motivated ;-) I had to get setup so I could hook a debugger into
> Turbine to get Intake figured out (that shows how much room for
> improvement there is!) so tracking down poor error reporting should
> be relatively easy. I'll try and put some patches together.
Just for interest sake, what debugger are you using?
> > I have always used (note the capitals). This
> > should be mentioned in the Intake Howto.
>
> A note in the howto would be a good interim measure. Not munging the
> names the user specifies would be better :-)
I think the names must be javabean compliant for the reflection to
work, so I am pretty sure they need to be munged...
> > TurbineException for you to retrieve its nested exception so you
> > can log a decent error message.
>
> You might want to look at using commons-lang's ChainedException (I
> think that's right)
NestedException :)
> rather the re-inventing it ;-) My prefered style
> is generally to define a ChainedExceptionInterface and
> ChainedExceptionHelper; that lets me extend existing exception
> classes where appropriate, and include chaining functionality on
> every exception :)
Yeah, that is what the TurbineException class in the Turbine 3
repository does, and I am pretty sure it will make it into the Turbine
2.x repository eventually.
Regards,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: intake and turbine 2 issues (was Re: TDK 2.2 glitches)
Posted by Laurie Harper <zo...@holoweb.net>.
Rodney Schneider wrote:
> Would it be possible for you to either supply a patch or at least log
> an issue in Scarab for this problem?
I can certainly file bug reports. Posting patches will need me to get
motivated ;-) I had to get setup so I could hook a debugger into Turbine
to get Intake figured out (that shows how much room for improvement
there is!) so tracking down poor error reporting should be relatively
easy. I'll try and put some patches together.
> I have always used (note the capitals). This
> should be mentioned in the Intake Howto.
A note in the howto would be a good interim measure. Not munging the
names the user specifies would be better :-)
> The exception and error handling in Turbine leaves much to be desired.
> Nearly everything 'throws Exception'. I don't think the Turbine
> developers had much experience with exception handling when they wrote
Yeah, that would be symtomatic. Exception handling takes a little
getting used to.
> the code. Torque has recently been changed to throw TorqueException.
> The parts of Turbine that currently throw Exception should either throw
> TurbineException or a subclass of it. I have attached a patch to
Agree 100%.
> TurbineException for you to retrieve its nested exception so you can
> log a decent error message.
You might want to look at using commons-lang's ChainedException (I think
that's right) rather the re-inventing it ;-) My prefered style is
generally to define a ChainedExceptionInterface and
ChainedExceptionHelper; that lets me extend existing exception classes
where appropriate, and include chaining functionality on every exception :)
> Now that Turbine 2.2 has been released, expect the Turbine 2.x codebase
> to be majorly overhauled and cleaned up. You are more than welcome to
> help with this effort :)
<grin> no doubt! I'm sort of waiting on seeing whether Turbine has a
viable future at the moment after reading so many 'Turbine 3 was a
failed experiment' / 'the core committers have moved on to other things'
/ 'Plexus/Sumit it the One True Way Forward' threads on this list over
the last two or three months. I'm not endorsing any of those sentiments,
only worrying about whether they're valid ;-) I saw Hennings recent
post that was somewhat in the other direction, which is encouraging, but
I would like to see more positive affirmation of Turbine's future. I'll
join the dev list and see what the climate's like.
> Eventually the services will be decoupled from Turbine, but how this is
> going to be done has not yet been decided. Torque has already been
> completely decoupled.
I think I'd be more interested in helping this happen than fixing up
what's there now. That means a bit more learning curve but it would be
taking things forward rather than sideways ;-)
L.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
intake and turbine 2 issues (was Re: TDK 2.2 glitches)
Posted by Rodney Schneider <ro...@actf.com.au>.
On Tue, 10 Dec 2002 13:24, you wrote:
> if anything is set up at all wrong you get a null pointer exception;
Would it be possible for you to either supply a patch or at least log
an issue in Scarab for this problem?
> the property names you specify in your inteke.xml get capitalised
> (i.e. if you have <field name="someName" ... you have to refer to it
> as SomeName or you get exceptions);
I have always used <field name="SomeName"> (note the capitals). This
should be mentioned in the Intake Howto.
> IntakeTool.get() is declared 'throws Exception' so you have to wrap
> calls to it, although it only throws TurbineException -- and when it
> does so, e.g. due to a typo in a template, the log just tells you
> that a TurbineException was thrown, without the exception message, so
> you have no idea why... And that's just what I ran into in one
> evening! :-)
The exception and error handling in Turbine leaves much to be desired.
Nearly everything 'throws Exception'. I don't think the Turbine
developers had much experience with exception handling when they wrote
the code. Torque has recently been changed to throw TorqueException.
The parts of Turbine that currently throw Exception should either throw
TurbineException or a subclass of it. I have attached a patch to
TurbineException for you to retrieve its nested exception so you can
log a decent error message.
Now that Turbine 2.2 has been released, expect the Turbine 2.x codebase
to be majorly overhauled and cleaned up. You are more than welcome to
help with this effort :)
> I like what Intake provides, I just think it could be a lot easier to
> setup and use. That exception from IntakeTool.get() is a real killer.
>
> > Also, someone needs to backport the fixes that have been made to
> > the Fulcrum version of Intake to Turbine 2.x. I have been meaning
> > to do this for a while, but haven't found the time.
>
> Wouldn't it make more sense for Turbine just to switch to the Fulcrum
> version, if that's being actively developed? I thought Turbine was
> migrating to decoupled services in general. Or was that just for
> Torque?
Eventually the services will be decoupled from Turbine, but how this is
going to be done has not yet been decided. Torque has already been
completely decoupled.
Regards,
-- Rodney
Re: TDK 2.2 glitches
Posted by Laurie Harper <zo...@holoweb.net>.
Rodney Schneider wrote:
> Yeah, the Intake docs need a lot of work, but once you get used to
> Intake it works quite well and does save quite a bit of development
> work.
The docs are only half the problem: if anything is set up at all wrong
you get a null pointer exception; the property names you specify in your
inteke.xml get capitalised (i.e. if you have <field name="someName" ...
you have to refer to it as SomeName or you get exceptions);
IntakeTool.get() is declared 'throws Exception' so you have to wrap
calls to it, although it only throws TurbineException -- and when it
does so, e.g. due to a typo in a template, the log just tells you that a
TurbineException was thrown, without the exception message, so you have
no idea why... And that's just what I ran into in one evening! :-)
I like what Intake provides, I just think it could be a lot easier to
setup and use. That exception from IntakeTool.get() is a real killer.
> Also, someone needs to backport the fixes that have been made to the
> Fulcrum version of Intake to Turbine 2.x. I have been meaning to do
> this for a while, but haven't found the time.
Wouldn't it make more sense for Turbine just to switch to the Fulcrum
version, if that's being actively developed? I thought Turbine was
migrating to decoupled services in general. Or was that just for Torque?
L.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TDK 2.2 glitches
Posted by Rodney Schneider <ro...@actf.com.au>.
On Tue, 10 Dec 2002 12:40, you wrote:
> Well the reason I migrated was because I was having so much trouble
> getting Intake to work and thought either the HOWTO was out of sync
> with respect to 2.1 or the version of Intake was bad. It turns out
> Intake's just a pig to get going, but that's one more peice of
> Turbine I'm using now :)
Yeah, the Intake docs need a lot of work, but once you get used to
Intake it works quite well and does save quite a bit of development
work.
Also, someone needs to backport the fixes that have been made to the
Fulcrum version of Intake to Turbine 2.x. I have been meaning to do
this for a while, but haven't found the time.
Regards,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TDK 2.2 glitches
Posted by Laurie Harper <zo...@holoweb.net>.
Well the reason I migrated was because I was having so much trouble
getting Intake to work and thought either the HOWTO was out of sync with
respect to 2.1 or the version of Intake was bad. It turns out Intake's
just a pig to get going, but that's one more peice of Turbine I'm using
now :)
L.
Rodney Schneider wrote:
> On Tue, 10 Dec 2002 06:41, you wrote:
>
>
> >>Between all of us we should be able to come up with a pretty good
> >>Migration Howto.
> >
> >As it turns out, I didn't need to do anything more than copy the new
> >jars into my project and update my Turbine.properties. I guess I'm
> >just not using that much of Turbine yet :-)
>
>
> Lucky you :) I wish I could say the same thing... the migration
> process was rather painful for us :(
>
> -- Rodney
>
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TDK 2.2 glitches
Posted by Rodney Schneider <ro...@actf.com.au>.
On Tue, 10 Dec 2002 06:41, you wrote:
> > Between all of us we should be able to come up with a pretty good
> > Migration Howto.
>
> As it turns out, I didn't need to do anything more than copy the new
> jars into my project and update my Turbine.properties. I guess I'm
> just not using that much of Turbine yet :-)
Lucky you :) I wish I could say the same thing... the migration
process was rather painful for us :(
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TDK 2.2 glitches
Posted by Laurie Harper <zo...@holoweb.net>.
Rodney Schneider wrote:
> The build.properties file that comes with the TDK should be documented
> thoroughly. Each property should be explained. Patches are always
> welcome :)
I was wondering when someone would say that :-) I'll see if I can
transform my commentary into a set of patches this evening.
> If you could document what you do as you go it would be much
> appreciated. Quinton has documented the migration process a bit here:
>
> http://archives.apache.org/eyebrowse/ReadMsg?listName=turbine-user@jakarta.apache.org&msgNo=12729
>
> Between all of us we should be able to come up with a pretty good
> Migration Howto.
As it turns out, I didn't need to do anything more than copy the new
jars into my project and update my Turbine.properties. I guess I'm just
not using that much of Turbine yet :-)
L.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>