On 1/4/02 12:52 PM, "Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote:
> If you don't want to read such words, please use a Killfile.
> X-Copyright: (C) 1996-2002 Henning Schmiedehausen
> X-No-Archive: yes
> X-Newsreader: NN version 6.5.1 (NOV)
>
> Jason van Zyl <[EMAIL PROTECTED]> writes:
>
>> Hi,
>
>> All users that have responded on the list want to wait for the decoupled
>> versions of torque and fulcrum to be available for use in 2.x before we
>> release. We have discussed this briefly in IRC but how about the following
>> for a plan.
>
> Hm,
>
> I pulled some changes from the 2.2 code because of compatibility
> issues. So I want to know how exactly this changeover from 2.1 to 2.2
> + fulcrum + torque will happen. At least the base classes of the whole
> om system will change from org.apache.turbine to org.apache.torque,
> wouldn't it? Same goes to the service environment.
By default the couple versions of the services framework and torque will be
used. You will have to specify the use the decoupled versions. If you are
ready to move forward then you can, and is highly recommended, if not than
things will work as before.
> We pulled the interface changes from T2.2beta because some users had
> to recompile.
No, not because they had to recompile but that it wouldn't compile. I
wouldn't have minded recompiling but your changes didn't work without code
changes.
>If I use T2 + Fulcrum + Torque with one of my projects,
> I have major _rewrites_ of my code to get it to run.
You do not have to use Fulcrum or Torque if you don't want.
> or am I seeing something wrong here? Will we keep code in both Torque
> and T2? If yes, the I really see no point in using them.
We will keep both versions around for compatibility but it will definitely
be recommended that people move forward as many people aren't going to be
contributing toward the coupled versions of the tools.
This will allow users to move forward if they want and we can figure out
some migration strategies for people who want to wait. At the very least
there will be issues dealt with on the mailing list to help people move
forward.
>> i) Introduction of lifecycle interfaces in org.apache.stratum.lifecycle.
>
> [...]
>
> I always see postings about "that we will have now, that we will make
> new, that will change...". But the last released TDK is what? six
> months old?
We haven't released but lots has been going on. I don't care that we haven't
released. It would be nice and it will be more frequent but probably not
during all these changes.
> And I have the "fun" of working with the Torque code today
> a little and honestly, it makes me wanting to throw up. Look at this:
>
> --- cut ---
> [...]
> private static String getDatabaseProperty(String db, String prop)
> {
> return configuration.getString( new StringBuffer("database.")
> .append(db)
> .append('.')
> .append(prop)
> .toString(), "" );
> }
> [...]
> private static final String getProperty(String dbName, String prop)
> {
> return ("database." + dbName + '.' + prop);
> }
> [...]
> --- cut ---
>
> What is wrong with this picture? And this is not exactly in an unimportant
> piece of Torque but in o.a.t.Torque.java
>
> I can point out some race conditions, some unclear code and I still
> ask myself why the Torque class must know about threads running in the
> DatabaseMap classes.
I could hand you a list as long as my arm, so what? Document them and post
tests and fixes.
> Ok, I know that bullshit talks and code walks. But I'm _so_ unhappy
> with the current state of the OM system of Torque/Turbine _and_ I have
> almost a week of time coming up, that I will work on a prototype of a
> "Torque next generation" the next week.
Please read Scott Ambler's papers before you go off designing something on
your own. Time would be best spent understanding his design as I believe
it's sound and well documented and will provide something better than what
we currently have.
> BTW: I'd like to reserve "Turbine-Twister" for this. ;-) (Twister
> seems to be almost the only synonym that Webster gave me for
> "Torque". )
>
> My intention is not "being compatible to Torque" but "keeping the
> style of the Turbine OM system alive while attacking the inadequacies
> and shortcomings of the current system. I HATE THE STATIC PEERS FROM
> THE VERY BOTTOM OF MY HEART. Yet I will keep facade classes for the
> people who want to use it.
Yes, it's been discussed. I'm sure many of us have the same dislikes that
you have.
> I currently have about 10% of the code ready and I tackled some of the
> heavier stuff first (Torque, Criteria, BasePeer). I will basically
> keep the Transformation stuff as it is but (of course) tackle the
> templates.
Again, I urge you to read Scott Ambler's papers. I myself am not really
looking anything else and I hope we can incorporate his designs with what we
have. I have refrained myself from starting from scratch.
> Ideas I will work on from the README.txt
>
> --- cut ---
> o Torque should be fully functional on its own, but right now
> it doesn't work as a persistence layer without the DBService
> in Fulcrum.
It is now. And the DBService will go away. At least I want it to.
> The classes should be moved from Fulcrum into
> this repository and Torque should be made to work on its own
> and be embeddable in applications. The DBService in Fulcrum
> should be a wrapper around Torque.
It's what it is now. This has been done too.
> o Separate the connection pool and make it pluggable
> so that torque can easily be integrated into other application
> that already use PoolMan, or the commons connection pool, or
> the struts connection pool or whatever
> --- cut ---
>
> I have also some notes already written down:
You should come to IRC as we talk about these things a lot there. Possibly
more than we should but all these things have been discussed. We were just
talking about it now actually.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
