You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Quinton McCombs <qm...@nequalsone.com> on 2002/11/22 18:59:30 UTC
Migrating to T2.2RC1
I have recently migrated to T2.2RC1 from T2.1. I decided to use the
decoupled torque.
Here is a short list of what I went through to complete the migration
(not actually completed). I will post a more detailed message sometime
over the next week or so.
1. Imports need to be changed. I think that everyone understand this
one.
2. Dealing with transactions and obtaining/releasing database
connections.
All references to TurbineDB and DBConnection must be changed. There
were only a few place in my application where I needed to obtain a
DBConnection object. It was usually for transaction control.
To make this work with the decoupled torque, I used
o.a.torque.util.Transaction and o.a.torque.Torque. Check the javadocs
and you should easily understand how to correctly use them.
3. Abstract classes & torque.
I had several classes persisting to the same database tables in version
2.1. The new version of torque defines an abstract method called copy()
which will return a copy of the object for you. This must be defined in
you classes which extend whatever base class represents the table. This
is going to be really easy... Torque will define a copyInto() method
for you in the base class. Your implementation just needs to call that
method passing a new instance of the sub class.
4. Primary keys are no longer instances of ObjectKey.
This may have been my second biggest headache. Torque will now
generate your classes to use int or Integer (depending upon the setting
of javaType and defaultJavaType in xxx-schema.xml). That is also
assuming that you used numbers for your primary keys.
5. Torque generated TurbineUser and other Turbine related tables.
To stop this from happening rename you turbine-schema.xml file to
turbine-schema.xml.nogenerate (or anything else for that matter). It
did not do any harm to generate these files but it poses a problem if
you reference TurbineUser (or similar object) in your .om classes and
forget to import the correct version.
6. Extending turbine user
My application had a very minor extension to TurbineUser. However,
this is where I spent the most time during the migration. The fact that
torque generated the Turbine related tables made me think that life was
going to be much easier in this release. As I started down the road of
making changes to turbine-schema.xml to make my extensions, I started to
realize what a mistake I had made.
Using Henning's DB security service seemed to be an easy answer.
However, in the end, I could never make it work. My final road block on
this path was the fact that TemplateSessionValidator would put an
instance of o.a.t.om.security.TurbineUser into the session. Granted, I
could have rewritten the validator... It was also going to be a pain
because RunData expects the User object to implement
o.a.t.om.security.User. There are also still a few places where (like
TemplateSessionValidator) where o.a.t.services.TurbineSecurityService is
still coupled.
In the end, I went the route of extending via the old 2.1 method. Some
changes had to be made to get this to work with the new version but it
was MUCH easier that the first approach that I took.
7. Scheduled jobs - still in progress
Right now I simply turned off the job scheduler. It threw an exception
during startup as soon as it tried to load the first job from the
database tables. I have not looked at this at all.
8. XMLRPC - still in progress
Right now it is turned off. I hope that I don't run into any problems
with it.
9. Logging
It appears that you need to be using Log4J for your logging if you want
any toque messages. This should also hold true for fulcrum if you
decide to use it.
I have actually found that I like Log4J much better than whatever the
default was in 2.1. It took a little while to figure out how to get the
settings configured correctly but after that, no problems.
10. Configuring Torque.properties
It took me a little while to figure out how to get those settings
correct to work with Oracle. I finally found a posting on the mailing
list that showed the setting to configure the dsfactory. Without those
settings, torque threw an exception started the ID broker.
Well, like I said, that is the short version. I will try to get more
detail broken into several postings. Hopefully, by the time I am ready,
Wiki will be ready for use and I will just put it there.
--
Quinton McCombs <qm...@nequalsone.com>
NEqualsOne
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Migrating to T2.2RC1
Posted by Martin Poeschl <mp...@marmot.at>.
Quinton McCombs wrote:
>I think that I could do that.
>
great!
martin
>
>
>On Fri, 2002-11-22 at 12:09, Martin Poeschl wrote:
>
>
>
>>could you please write it in xdoc format?
>>i think it would be important to have a migration howto added to the site
>>
>>martin
>>
>>Quinton McCombs wrote:
>>
>>
>>
>>>I have recently migrated to T2.2RC1 from T2.1. I decided to use the
>>>decoupled torque.
>>>
>>>Here is a short list of what I went through to complete the migration
>>>(not actually completed). I will post a more detailed message sometime
>>>over the next week or so.
>>>
>>>1. Imports need to be changed. I think that everyone understand this
>>>one.
>>>
>>>2. Dealing with transactions and obtaining/releasing database
>>>connections.
>>> All references to TurbineDB and DBConnection must be changed. There
>>>were only a few place in my application where I needed to obtain a
>>>DBConnection object. It was usually for transaction control.
>>> To make this work with the decoupled torque, I used
>>>o.a.torque.util.Transaction and o.a.torque.Torque. Check the javadocs
>>>and you should easily understand how to correctly use them.
>>>
>>>3. Abstract classes & torque.
>>> I had several classes persisting to the same database tables in version
>>>2.1. The new version of torque defines an abstract method called copy()
>>>which will return a copy of the object for you. This must be defined in
>>>you classes which extend whatever base class represents the table. This
>>>is going to be really easy... Torque will define a copyInto() method
>>>for you in the base class. Your implementation just needs to call that
>>>method passing a new instance of the sub class.
>>>
>>>4. Primary keys are no longer instances of ObjectKey.
>>> This may have been my second biggest headache. Torque will now
>>>generate your classes to use int or Integer (depending upon the setting
>>>of javaType and defaultJavaType in xxx-schema.xml). That is also
>>>assuming that you used numbers for your primary keys.
>>>
>>>5. Torque generated TurbineUser and other Turbine related tables.
>>> To stop this from happening rename you turbine-schema.xml file to
>>>turbine-schema.xml.nogenerate (or anything else for that matter). It
>>>did not do any harm to generate these files but it poses a problem if
>>>you reference TurbineUser (or similar object) in your .om classes and
>>>forget to import the correct version.
>>>
>>>6. Extending turbine user
>>> My application had a very minor extension to TurbineUser. However,
>>>this is where I spent the most time during the migration. The fact that
>>>torque generated the Turbine related tables made me think that life was
>>>going to be much easier in this release. As I started down the road of
>>>making changes to turbine-schema.xml to make my extensions, I started to
>>>realize what a mistake I had made.
>>> Using Henning's DB security service seemed to be an easy answer.
>>>However, in the end, I could never make it work. My final road block on
>>>this path was the fact that TemplateSessionValidator would put an
>>>instance of o.a.t.om.security.TurbineUser into the session. Granted, I
>>>could have rewritten the validator... It was also going to be a pain
>>>because RunData expects the User object to implement
>>>o.a.t.om.security.User. There are also still a few places where (like
>>>TemplateSessionValidator) where o.a.t.services.TurbineSecurityService is
>>>still coupled.
>>> In the end, I went the route of extending via the old 2.1 method. Some
>>>changes had to be made to get this to work with the new version but it
>>>was MUCH easier that the first approach that I took.
>>>
>>>7. Scheduled jobs - still in progress
>>> Right now I simply turned off the job scheduler. It threw an exception
>>>during startup as soon as it tried to load the first job from the
>>>database tables. I have not looked at this at all.
>>>
>>>8. XMLRPC - still in progress
>>> Right now it is turned off. I hope that I don't run into any problems
>>>with it.
>>>
>>>9. Logging
>>> It appears that you need to be using Log4J for your logging if you want
>>>any toque messages. This should also hold true for fulcrum if you
>>>decide to use it.
>>> I have actually found that I like Log4J much better than whatever the
>>>default was in 2.1. It took a little while to figure out how to get the
>>>settings configured correctly but after that, no problems.
>>>
>>>10. Configuring Torque.properties
>>> It took me a little while to figure out how to get those settings
>>>correct to work with Oracle. I finally found a posting on the mailing
>>>list that showed the setting to configure the dsfactory. Without those
>>>settings, torque threw an exception started the ID broker.
>>>
>>>
>>>Well, like I said, that is the short version. I will try to get more
>>>detail broken into several postings. Hopefully, by the time I am ready,
>>>Wiki will be ready for use and I will just put it there.
>>>
>>>
>>>
>>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
>
>>Quinton McCombs<
>>
>>
>Strategic Planner, NEqualsOne
> 1800 International Park Drive
> Suite 205
> Birmingham, AL 35243
>p: 205.324.8005 x121 800.466.1337
> f: 205.324.7008
>e: qmccombs@NEqualsOne.com
> www.NEqualsOne.com
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Migrating to T2.2RC1
Posted by Quinton McCombs <qm...@nequalsone.com>.
I think that I could do that.
On Fri, 2002-11-22 at 12:09, Martin Poeschl wrote:
> could you please write it in xdoc format?
> i think it would be important to have a migration howto added to the site
>
> martin
>
> Quinton McCombs wrote:
>
> >I have recently migrated to T2.2RC1 from T2.1. I decided to use the
> >decoupled torque.
> >
> >Here is a short list of what I went through to complete the migration
> >(not actually completed). I will post a more detailed message sometime
> >over the next week or so.
> >
> >1. Imports need to be changed. I think that everyone understand this
> >one.
> >
> >2. Dealing with transactions and obtaining/releasing database
> >connections.
> > All references to TurbineDB and DBConnection must be changed. There
> >were only a few place in my application where I needed to obtain a
> >DBConnection object. It was usually for transaction control.
> > To make this work with the decoupled torque, I used
> >o.a.torque.util.Transaction and o.a.torque.Torque. Check the javadocs
> >and you should easily understand how to correctly use them.
> >
> >3. Abstract classes & torque.
> > I had several classes persisting to the same database tables in version
> >2.1. The new version of torque defines an abstract method called copy()
> >which will return a copy of the object for you. This must be defined in
> >you classes which extend whatever base class represents the table. This
> >is going to be really easy... Torque will define a copyInto() method
> >for you in the base class. Your implementation just needs to call that
> >method passing a new instance of the sub class.
> >
> >4. Primary keys are no longer instances of ObjectKey.
> > This may have been my second biggest headache. Torque will now
> >generate your classes to use int or Integer (depending upon the setting
> >of javaType and defaultJavaType in xxx-schema.xml). That is also
> >assuming that you used numbers for your primary keys.
> >
> >5. Torque generated TurbineUser and other Turbine related tables.
> > To stop this from happening rename you turbine-schema.xml file to
> >turbine-schema.xml.nogenerate (or anything else for that matter). It
> >did not do any harm to generate these files but it poses a problem if
> >you reference TurbineUser (or similar object) in your .om classes and
> >forget to import the correct version.
> >
> >6. Extending turbine user
> > My application had a very minor extension to TurbineUser. However,
> >this is where I spent the most time during the migration. The fact that
> >torque generated the Turbine related tables made me think that life was
> >going to be much easier in this release. As I started down the road of
> >making changes to turbine-schema.xml to make my extensions, I started to
> >realize what a mistake I had made.
> > Using Henning's DB security service seemed to be an easy answer.
> >However, in the end, I could never make it work. My final road block on
> >this path was the fact that TemplateSessionValidator would put an
> >instance of o.a.t.om.security.TurbineUser into the session. Granted, I
> >could have rewritten the validator... It was also going to be a pain
> >because RunData expects the User object to implement
> >o.a.t.om.security.User. There are also still a few places where (like
> >TemplateSessionValidator) where o.a.t.services.TurbineSecurityService is
> >still coupled.
> > In the end, I went the route of extending via the old 2.1 method. Some
> >changes had to be made to get this to work with the new version but it
> >was MUCH easier that the first approach that I took.
> >
> >7. Scheduled jobs - still in progress
> > Right now I simply turned off the job scheduler. It threw an exception
> >during startup as soon as it tried to load the first job from the
> >database tables. I have not looked at this at all.
> >
> >8. XMLRPC - still in progress
> > Right now it is turned off. I hope that I don't run into any problems
> >with it.
> >
> >9. Logging
> > It appears that you need to be using Log4J for your logging if you want
> >any toque messages. This should also hold true for fulcrum if you
> >decide to use it.
> > I have actually found that I like Log4J much better than whatever the
> >default was in 2.1. It took a little while to figure out how to get the
> >settings configured correctly but after that, no problems.
> >
> >10. Configuring Torque.properties
> > It took me a little while to figure out how to get those settings
> >correct to work with Oracle. I finally found a posting on the mailing
> >list that showed the setting to configure the dsfactory. Without those
> >settings, torque threw an exception started the ID broker.
> >
> >
> >Well, like I said, that is the short version. I will try to get more
> >detail broken into several postings. Hopefully, by the time I am ready,
> >Wiki will be ready for use and I will just put it there.
> >
> >
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>Quinton McCombs<
Strategic Planner, NEqualsOne
1800 International Park Drive
Suite 205
Birmingham, AL 35243
p: 205.324.8005 x121 800.466.1337
f: 205.324.7008
e: qmccombs@NEqualsOne.com
www.NEqualsOne.com
Re: Migrating to T2.2RC1
Posted by Martin Poeschl <mp...@marmot.at>.
could you please write it in xdoc format?
i think it would be important to have a migration howto added to the site
martin
Quinton McCombs wrote:
>I have recently migrated to T2.2RC1 from T2.1. I decided to use the
>decoupled torque.
>
>Here is a short list of what I went through to complete the migration
>(not actually completed). I will post a more detailed message sometime
>over the next week or so.
>
>1. Imports need to be changed. I think that everyone understand this
>one.
>
>2. Dealing with transactions and obtaining/releasing database
>connections.
> All references to TurbineDB and DBConnection must be changed. There
>were only a few place in my application where I needed to obtain a
>DBConnection object. It was usually for transaction control.
> To make this work with the decoupled torque, I used
>o.a.torque.util.Transaction and o.a.torque.Torque. Check the javadocs
>and you should easily understand how to correctly use them.
>
>3. Abstract classes & torque.
> I had several classes persisting to the same database tables in version
>2.1. The new version of torque defines an abstract method called copy()
>which will return a copy of the object for you. This must be defined in
>you classes which extend whatever base class represents the table. This
>is going to be really easy... Torque will define a copyInto() method
>for you in the base class. Your implementation just needs to call that
>method passing a new instance of the sub class.
>
>4. Primary keys are no longer instances of ObjectKey.
> This may have been my second biggest headache. Torque will now
>generate your classes to use int or Integer (depending upon the setting
>of javaType and defaultJavaType in xxx-schema.xml). That is also
>assuming that you used numbers for your primary keys.
>
>5. Torque generated TurbineUser and other Turbine related tables.
> To stop this from happening rename you turbine-schema.xml file to
>turbine-schema.xml.nogenerate (or anything else for that matter). It
>did not do any harm to generate these files but it poses a problem if
>you reference TurbineUser (or similar object) in your .om classes and
>forget to import the correct version.
>
>6. Extending turbine user
> My application had a very minor extension to TurbineUser. However,
>this is where I spent the most time during the migration. The fact that
>torque generated the Turbine related tables made me think that life was
>going to be much easier in this release. As I started down the road of
>making changes to turbine-schema.xml to make my extensions, I started to
>realize what a mistake I had made.
> Using Henning's DB security service seemed to be an easy answer.
>However, in the end, I could never make it work. My final road block on
>this path was the fact that TemplateSessionValidator would put an
>instance of o.a.t.om.security.TurbineUser into the session. Granted, I
>could have rewritten the validator... It was also going to be a pain
>because RunData expects the User object to implement
>o.a.t.om.security.User. There are also still a few places where (like
>TemplateSessionValidator) where o.a.t.services.TurbineSecurityService is
>still coupled.
> In the end, I went the route of extending via the old 2.1 method. Some
>changes had to be made to get this to work with the new version but it
>was MUCH easier that the first approach that I took.
>
>7. Scheduled jobs - still in progress
> Right now I simply turned off the job scheduler. It threw an exception
>during startup as soon as it tried to load the first job from the
>database tables. I have not looked at this at all.
>
>8. XMLRPC - still in progress
> Right now it is turned off. I hope that I don't run into any problems
>with it.
>
>9. Logging
> It appears that you need to be using Log4J for your logging if you want
>any toque messages. This should also hold true for fulcrum if you
>decide to use it.
> I have actually found that I like Log4J much better than whatever the
>default was in 2.1. It took a little while to figure out how to get the
>settings configured correctly but after that, no problems.
>
>10. Configuring Torque.properties
> It took me a little while to figure out how to get those settings
>correct to work with Oracle. I finally found a posting on the mailing
>list that showed the setting to configure the dsfactory. Without those
>settings, torque threw an exception started the ID broker.
>
>
>Well, like I said, that is the short version. I will try to get more
>detail broken into several postings. Hopefully, by the time I am ready,
>Wiki will be ready for use and I will just put it there.
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>