You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Eric Pugh <ep...@upstate.com> on 2003/08/13 00:44:30 UTC
Can we delete RunDataFactory?
Hi all,
I noticed that RunDataFactory is really old. Notice this comment:
// NOTE: getRunData( HttpServletRequest req,
// HttpServletResponse res ) has been deprecated 3-3-2000.
// Wait a couple months (before Turbine 1.0) and remove this
// method.
I don't mind doing the work, but I think we should remove it as 1.0 has been
out a bit...
:-)
Eric
-----Original Message-----
From: Eric Emminger [mailto:eric@ericemminger.com]
Sent: Monday, August 11, 2003 5:39 PM
To: Turbine Developers List
Subject: Re: Reg: Error Occurred in Ohioedge CRM.
Velmurugan (Java) wrote:
> Hi All,
>
> When we run the application called "Ohioedge CRM" and got the following
error. Kindly help us how to trace out the solutions.I have followed all the
instrunctions which are given in installation document.
>
> Software's used.
> =============
>
> 1. JDK1.4.1
> 2. JBoss-3.2.1
>
> Platform
> =======
>
> Win-2K Professional.
>
>
> ERROR
>
============================================================================
==================
>
> 2003-08-09 14:54:46,363 INFO [STDOUT] 1304306 [Thread-44] DEBUG
org.apache.torque.oid.IDBroker - IDBroker thread was started.
> 2003-08-09 14:54:48,365 WARN [org.apache.torque.oid.IDBroker] IDBroker is
being used with db 'default', which does not support transactions. IDBroker
attempts to use transactions to limit the possibility of duplicate key
generation. Without transactions, duplicate key generation is possible if
multiple JVMs are used or other means are used to write to the database.
> 2003-08-09 14:54:48,375 INFO [STDOUT] 1306308 [PoolThread-9] WARN
org.apache.torque.oid.IDBroker - IDBroker is being used with db 'default',
which does not support transactions. IDBroker attempts to use transactions
to limit the possibility of duplicate key generation. Without transactions,
duplicate key generation is possible if multiple JVMs are used or other
means are used to write to the database.
> 2003-08-09 14:54:50,368 ERROR [org.apache.torque.util.BasePeer]
org.apache.torque.TorqueException: Connection is broken: Connection refused:
connect
This is probably the real problem. Torque is unable to connect to your
database. Make sure you've configured your Ohioedge CRM application
correctly, which may involve configuring Torque. If you need help with
Torque, see the Torque site which is now at
http://db.apache.org/torque/
Otherwise, you may need to contact Ohioedge.
> 2003-08-09 14:54:50,378 INFO [STDOUT] 1308311 [PoolThread-9] ERROR
org.apache.torque.util.BasePeer - org.apache.torque.TorqueException:
Connection is broken: Connection refused: connect
> 2003-08-09 14:54:50,388 ERROR [org.apache.torque.util.BasePeer] A FATAL
ERROR has occurred which should not have happened under any circumstance.
Please notify the Turbine developers <tu...@jakarta.apache.org> and
give as many details as possible (including the error stack trace).
> java.lang.Error: Error in BasePeer.initTableSchema(TURBINE_USER):
Connection is broken: Connection refused: connect
I'm fairly sure your problem is NOT with Turbine.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by Quinton McCombs <qu...@qdog.org>.
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Monday, August 18, 2003 3:55 PM
> To: turbine-dev@jakarta.apache.org
> Subject: Re: [PROPOSAL] Move Torque related classes to
> seperate turbine module.
>
>
> I don't like the fact that components from the
> AvalonComponentService can't and don't use Logging as
> transparently as Turbine native service. I'd like to get some
> sort of adapter that a container provides the components with
> a logging facility a la commons-logging. I don't know whether
> this is possible but getting one large log with just "avalon"
> as facility and no class names (which IMHO only leads to
> developers putting the class names into each and every
> logging statement) is not desireable.
There is a way around this. I seem to remember someone else patching one or
more of the fulcrum components that I converted to use the class name.
Re: [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>> With the rifts that opened inside the Avalon project lately and all
>> the bad blood going on between the various authors, I'm not sure that
>> using anything beyond the Avalon Interface stuff would be a wise
>> decision. I have just skimmed the various discussions but I don't like
>> the fact that there seems to be no clear idea where to head with
>> Avalon in the future. There has been even talk about "redoing the
>> interfaces" and "split up the development", so I don't feel too good
>> about Avalon currently.
>>
>I know what you mean about not being sure about ECM. I have been perusing
>some competing IoC containers like picocontainer, and some the Avalon
>containers. I am somewhat of the opinion that while ECM may not be the
>best, it does seem to work. And eventually we may want to jump to
>Fortress/Merlin/Picocontainer/name your favorite container!
I asked about this on avalon-dev a while ago and some of the avalon
people told me, that Fortress would be nice in some aspects,
e.g. Logging.
I don't like the fact that components from the AvalonComponentService
can't and don't use Logging as transparently as Turbine native
service. I'd like to get some sort of adapter that a container
provides the components with a logging facility a la
commons-logging. I don't know whether this is possible but getting one
large log with just "avalon" as facility and no class names (which
IMHO only leads to developers putting the class names into each and
every logging statement) is not desireable.
Some of the avalon people told me that fortress can do this.
>I think for anything complex, what we want to do is what you did with the
>Torque component and the spice project does, which is to split the container
>wrapper from the core code.
Yep.
>I may dig in a little on the other containers, but I have a feeling which
>ever one we pick will be the wrong one in a years time...
>So, to sum up, I am going to plow forward on converting some more of the
>core Turbine components in fulcrum. I am going to write some more unit
>tests. Try and port the best of Turbine-2 to fulcrum. And any unit tests I
>write I may try and put back into Turbine. Then, as soon as we get 2.3 out
>of the way we can evaluate which fulcrum components to either move into the
>Turbine-2 cvs or to leave in fulcrum, which becomes a repo for avalon
>components.
>Sound good?
Yep. Getting some working code to play with is the best that can happen.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>> With the rifts that opened inside the Avalon project lately and all
>> the bad blood going on between the various authors, I'm not sure that
>> using anything beyond the Avalon Interface stuff would be a wise
>> decision. I have just skimmed the various discussions but I don't like
>> the fact that there seems to be no clear idea where to head with
>> Avalon in the future. There has been even talk about "redoing the
>> interfaces" and "split up the development", so I don't feel too good
>> about Avalon currently.
>>
>I know what you mean about not being sure about ECM. I have been perusing
>some competing IoC containers like picocontainer, and some the Avalon
>containers. I am somewhat of the opinion that while ECM may not be the
>best, it does seem to work. And eventually we may want to jump to
>Fortress/Merlin/Picocontainer/name your favorite container!
I asked about this on avalon-dev a while ago and some of the avalon
people told me, that Fortress would be nice in some aspects,
e.g. Logging.
I don't like the fact that components from the AvalonComponentService
can't and don't use Logging as transparently as Turbine native
service. I'd like to get some sort of adapter that a container
provides the components with a logging facility a la
commons-logging. I don't know whether this is possible but getting one
large log with just "avalon" as facility and no class names (which
IMHO only leads to developers putting the class names into each and
every logging statement) is not desireable.
Some of the avalon people told me that fortress can do this.
>I think for anything complex, what we want to do is what you did with the
>Torque component and the spice project does, which is to split the container
>wrapper from the core code.
Yep.
>I may dig in a little on the other containers, but I have a feeling which
>ever one we pick will be the wrong one in a years time...
>So, to sum up, I am going to plow forward on converting some more of the
>core Turbine components in fulcrum. I am going to write some more unit
>tests. Try and port the best of Turbine-2 to fulcrum. And any unit tests I
>write I may try and put back into Turbine. Then, as soon as we get 2.3 out
>of the way we can evaluate which fulcrum components to either move into the
>Turbine-2 cvs or to leave in fulcrum, which becomes a repo for avalon
>components.
>Sound good?
Yep. Getting some working code to play with is the best that can happen.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: What's left for 2.3 release?
Posted by Colin Chalmers <co...@maxware.nl>.
"Colin Chalmers" <co...@maxware.nl> writes:
>What still needs done for this (2.3 release) and how can I help?
Give me 12 hours of your time. ;-)
If I had them to give ...... ;-)
/c
I've brought the download dirs in shape on sunday. All that is left is
fix up a few links in the docs, tag and roll the RC1. I will do this
tonight, I've tagged a few hours for this right after work.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: What's left for 2.3 release?
Posted by Colin Chalmers <co...@maxware.nl>.
"Colin Chalmers" <co...@maxware.nl> writes:
>What still needs done for this (2.3 release) and how can I help?
Give me 12 hours of your time. ;-)
If I had them to give ...... ;-)
/c
I've brought the download dirs in shape on sunday. All that is left is
fix up a few links in the docs, tag and roll the RC1. I will do this
tonight, I've tagged a few hours for this right after work.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: What's left for 2.3 release?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Colin Chalmers" <co...@maxware.nl> writes:
>What still needs done for this (2.3 release) and how can I help?
Give me 12 hours of your time. ;-)
I've brought the download dirs in shape on sunday. All that is left is
fix up a few links in the docs, tag and roll the RC1. I will do this
tonight, I've tagged a few hours for this right after work.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: What's left for 2.3 release?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Colin Chalmers" <co...@maxware.nl> writes:
>What still needs done for this (2.3 release) and how can I help?
Give me 12 hours of your time. ;-)
I've brought the download dirs in shape on sunday. All that is left is
fix up a few links in the docs, tag and roll the RC1. I will do this
tonight, I've tagged a few hours for this right after work.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: What's left for 2.3 release?
Posted by Eric Pugh <ep...@upstate.com>.
The upshot on this stuff is that is all becomes relevant in a post 2.3
world. The only thing I can possible think that we might want to jigger
around before them is swapping the avalon component to using fortress or
something else.. But again, I think we need a 2.3 RC more!
Thanks Henning, can't wait to try it out!
Eric
> -----Original Message-----
> From: Colin Chalmers [mailto:colin.chalmers@maxware.nl]
> Sent: Monday, August 18, 2003 9:06 AM
> To: Turbine Developers List
> Subject: What's left for 2.3 release?
>
>
> I saw some discussion at the weekend concerning Torque
> releated stuff, is it
> better to keep that for a 2.4 release and try and get a 2.3
> release out the door
> soon?
>
> What still needs done for this (2.3 release) and how can I help?
>
> Colin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: What's left for 2.3 release?
Posted by Eric Pugh <ep...@upstate.com>.
The upshot on this stuff is that is all becomes relevant in a post 2.3
world. The only thing I can possible think that we might want to jigger
around before them is swapping the avalon component to using fortress or
something else.. But again, I think we need a 2.3 RC more!
Thanks Henning, can't wait to try it out!
Eric
> -----Original Message-----
> From: Colin Chalmers [mailto:colin.chalmers@maxware.nl]
> Sent: Monday, August 18, 2003 9:06 AM
> To: Turbine Developers List
> Subject: What's left for 2.3 release?
>
>
> I saw some discussion at the weekend concerning Torque
> releated stuff, is it
> better to keep that for a 2.4 release and try and get a 2.3
> release out the door
> soon?
>
> What still needs done for this (2.3 release) and how can I help?
>
> Colin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
What's left for 2.3 release?
Posted by Colin Chalmers <co...@maxware.nl>.
I saw some discussion at the weekend concerning Torque releated stuff, is it
better to keep that for a 2.4 release and try and get a 2.3 release out the door
soon?
What still needs done for this (2.3 release) and how can I help?
Colin
What's left for 2.3 release?
Posted by Colin Chalmers <co...@maxware.nl>.
I saw some discussion at the weekend concerning Torque releated stuff, is it
better to keep that for a 2.4 release and try and get a 2.3 release out the door
soon?
What still needs done for this (2.3 release) and how can I help?
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by Eric Pugh <ep...@upstate.com>.
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Sunday, August 17, 2003 7:51 PM
> To: turbine-dev@jakarta.apache.org
> Subject: Re: [PROPOSAL] Move Torque related classes to
> seperate turbine
> module.
>
>
> "Eric Pugh" <ep...@upstate.com> writes:
>
> >Henning,
>
> Hi,
>
> yes. I'm all +1 for this, however I'd prefer to go with some sort of
> "turbine-components" repository in the near future. Actually, I
> neither like the "fulcrum" name, nor do I think that we should've
> opened up another namespace like org.apache.fulcrum.
I agree, however I think the idea with many of the fulcrum components was
that they are not Turbine specific. It seems to me that something like the
DVSL service or Localization are really just a component, with no
dependencies on turbine. However, others that maybe have a reference to
rundata or something then are clearly turbine components and should be in
turbine-components. I actually think that to reduce all the cvs modules, we
would have jakarta-turbine-2/src for turbine and
jakarta-turbine-2/components for the components that are Turbine specific.
>
> Before you actually delete code from src/java, please talk with
> jmcnally and the other t3 developers/users, I know that they actually
> deploy/use Fulcrum and it wouldn't be nice from us (that we don't even
> use Fulcrum) to break code that they use.
Good point, I may just not worry about it for now.
>
> Personally, I'd prefer org.apache.turbine.components.<componentname>
> to make clear that this is really _turbine_ code. For other stuff,
> like the quartz scheduler: I wouldn't integrate this into the turbine
> repo itself. If this is a component that implements a scheduler and
> works in our context without changes: Fine. We put a "3rd party
> components that work with Turbine" on the web site, add a link and are
> done.
Techinically, any Avalon component is Turbine compatible. However, I can
see something like Quartz being third party, and then adding something that
makes Quartz work smoothly with Turbine in the Turbine cvs. For instance a
Turbine configuration -> Quartz configuration adapter.\
>
> >Did you get a chance to read my follow up email and look at
> the changes I
> >made in Fulcrum? After spending a stack of time trying to understand
> >Fulcrum, I think I ended up at the same point you are at,
> about the Avalon
> >components, and ditching the ServiceBroker stuff...
>
> Yes, I'm fine with this. But IMHO this is not really relevant to
> Turbine 2.3 but to future stuff. If you have time to work on this,
> cool.
>
> >So, in preperation for the post 2.3 future.. Should I
> continue down the
> >path I am? I am happy to slap in a quartz version of the
> scheduler as well.
> >(might throw in the wrapper to my JCrontab one as well ;-) ).
>
> The quartz scheduler has its own home page (don't know where, would
> have to look) and I'm fine with where it is. We should work with its
> author so it can be used with the AvalonComponentService in 2.3 (hint,
> hint. ;-) ) and in further Turbine stuff.
>
> >If we are happy with what I am doing, then I will start
> deleting code out of
> >/src/java and replacing it with the components. My only
> other question
> >though is should all the services become components? And
> any suggestions on
> >order...
>
> Reworking fulcrum is a nice thing, even if all we do in the future is
> just salvaging out the good bits. I don't even know whether there are
> good bits left. The turbine-2 code has a solid year more work in it,
> so it might have actually fallen behind turbine in some aspects.
My goal is to have solid unit tests for anything I port. So, I will try and
compare the Turbine-2 and fulcrum versions and try and pick up the best of
both. However, I may need extra eyes for this!
>
> The reactor build is cool, too (once we get a maven version to be
> actually usable with the reactor), but I'd like to still be able to
> build the various components separately if only for debugging. If you
> want to see an interdependence nightmare, try building a single Avalon
> package like "excalibur-component" from source. You will end up with
> almost everything from the avalon project checked out and building
> before you actually get what you want. I'd like to build a single
> component which fetches all of its dependencies from ibiblio.
The way the reactor is set up, you can build each individual component
seperatly. If it requires an earlier dependency, then that is versioned in
the project.xml, and can be retrieved from iBiblio.
>
> BTW: I'd prefer that we call jars of the various components broken out
> of fulcrum to be called fulcrum-<whatever>-<version>.jar. So there is
> clear where they come from.
I think they are!
>
> If you really have time on your hands ;-) , there was some suggestion
> on the avalon-dev list, that if we want to use an avalon container
> with the AvalonComponentService, ECM might not have been the best
> choice. Some developers proposed that we switch to Fortress which
> seems to have more advantages and the switch from ECM doesn't seem too
> big.
>
> With the rifts that opened inside the Avalon project lately and all
> the bad blood going on between the various authors, I'm not sure that
> using anything beyond the Avalon Interface stuff would be a wise
> decision. I have just skimmed the various discussions but I don't like
> the fact that there seems to be no clear idea where to head with
> Avalon in the future. There has been even talk about "redoing the
> interfaces" and "split up the development", so I don't feel too good
> about Avalon currently.
>
I know what you mean about not being sure about ECM. I have been perusing
some competing IoC containers like picocontainer, and some the Avalon
containers. I am somewhat of the opinion that while ECM may not be the
best, it does seem to work. And eventually we may want to jump to
Fortress/Merlin/Picocontainer/name your favorite container!
I think for anything complex, what we want to do is what you did with the
Torque component and the spice project does, which is to split the container
wrapper from the core code.
I may dig in a little on the other containers, but I have a feeling which
ever one we pick will be the wrong one in a years time...
So, to sum up, I am going to plow forward on converting some more of the
core Turbine components in fulcrum. I am going to write some more unit
tests. Try and port the best of Turbine-2 to fulcrum. And any unit tests I
write I may try and put back into Turbine. Then, as soon as we get 2.3 out
of the way we can evaluate which fulcrum components to either move into the
Turbine-2 cvs or to leave in fulcrum, which becomes a repo for avalon
components.
Sound good?
Eric
RE: [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by Eric Pugh <ep...@upstate.com>.
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Sunday, August 17, 2003 7:51 PM
> To: turbine-dev@jakarta.apache.org
> Subject: Re: [PROPOSAL] Move Torque related classes to
> seperate turbine
> module.
>
>
> "Eric Pugh" <ep...@upstate.com> writes:
>
> >Henning,
>
> Hi,
>
> yes. I'm all +1 for this, however I'd prefer to go with some sort of
> "turbine-components" repository in the near future. Actually, I
> neither like the "fulcrum" name, nor do I think that we should've
> opened up another namespace like org.apache.fulcrum.
I agree, however I think the idea with many of the fulcrum components was
that they are not Turbine specific. It seems to me that something like the
DVSL service or Localization are really just a component, with no
dependencies on turbine. However, others that maybe have a reference to
rundata or something then are clearly turbine components and should be in
turbine-components. I actually think that to reduce all the cvs modules, we
would have jakarta-turbine-2/src for turbine and
jakarta-turbine-2/components for the components that are Turbine specific.
>
> Before you actually delete code from src/java, please talk with
> jmcnally and the other t3 developers/users, I know that they actually
> deploy/use Fulcrum and it wouldn't be nice from us (that we don't even
> use Fulcrum) to break code that they use.
Good point, I may just not worry about it for now.
>
> Personally, I'd prefer org.apache.turbine.components.<componentname>
> to make clear that this is really _turbine_ code. For other stuff,
> like the quartz scheduler: I wouldn't integrate this into the turbine
> repo itself. If this is a component that implements a scheduler and
> works in our context without changes: Fine. We put a "3rd party
> components that work with Turbine" on the web site, add a link and are
> done.
Techinically, any Avalon component is Turbine compatible. However, I can
see something like Quartz being third party, and then adding something that
makes Quartz work smoothly with Turbine in the Turbine cvs. For instance a
Turbine configuration -> Quartz configuration adapter.\
>
> >Did you get a chance to read my follow up email and look at
> the changes I
> >made in Fulcrum? After spending a stack of time trying to understand
> >Fulcrum, I think I ended up at the same point you are at,
> about the Avalon
> >components, and ditching the ServiceBroker stuff...
>
> Yes, I'm fine with this. But IMHO this is not really relevant to
> Turbine 2.3 but to future stuff. If you have time to work on this,
> cool.
>
> >So, in preperation for the post 2.3 future.. Should I
> continue down the
> >path I am? I am happy to slap in a quartz version of the
> scheduler as well.
> >(might throw in the wrapper to my JCrontab one as well ;-) ).
>
> The quartz scheduler has its own home page (don't know where, would
> have to look) and I'm fine with where it is. We should work with its
> author so it can be used with the AvalonComponentService in 2.3 (hint,
> hint. ;-) ) and in further Turbine stuff.
>
> >If we are happy with what I am doing, then I will start
> deleting code out of
> >/src/java and replacing it with the components. My only
> other question
> >though is should all the services become components? And
> any suggestions on
> >order...
>
> Reworking fulcrum is a nice thing, even if all we do in the future is
> just salvaging out the good bits. I don't even know whether there are
> good bits left. The turbine-2 code has a solid year more work in it,
> so it might have actually fallen behind turbine in some aspects.
My goal is to have solid unit tests for anything I port. So, I will try and
compare the Turbine-2 and fulcrum versions and try and pick up the best of
both. However, I may need extra eyes for this!
>
> The reactor build is cool, too (once we get a maven version to be
> actually usable with the reactor), but I'd like to still be able to
> build the various components separately if only for debugging. If you
> want to see an interdependence nightmare, try building a single Avalon
> package like "excalibur-component" from source. You will end up with
> almost everything from the avalon project checked out and building
> before you actually get what you want. I'd like to build a single
> component which fetches all of its dependencies from ibiblio.
The way the reactor is set up, you can build each individual component
seperatly. If it requires an earlier dependency, then that is versioned in
the project.xml, and can be retrieved from iBiblio.
>
> BTW: I'd prefer that we call jars of the various components broken out
> of fulcrum to be called fulcrum-<whatever>-<version>.jar. So there is
> clear where they come from.
I think they are!
>
> If you really have time on your hands ;-) , there was some suggestion
> on the avalon-dev list, that if we want to use an avalon container
> with the AvalonComponentService, ECM might not have been the best
> choice. Some developers proposed that we switch to Fortress which
> seems to have more advantages and the switch from ECM doesn't seem too
> big.
>
> With the rifts that opened inside the Avalon project lately and all
> the bad blood going on between the various authors, I'm not sure that
> using anything beyond the Avalon Interface stuff would be a wise
> decision. I have just skimmed the various discussions but I don't like
> the fact that there seems to be no clear idea where to head with
> Avalon in the future. There has been even talk about "redoing the
> interfaces" and "split up the development", so I don't feel too good
> about Avalon currently.
>
I know what you mean about not being sure about ECM. I have been perusing
some competing IoC containers like picocontainer, and some the Avalon
containers. I am somewhat of the opinion that while ECM may not be the
best, it does seem to work. And eventually we may want to jump to
Fortress/Merlin/Picocontainer/name your favorite container!
I think for anything complex, what we want to do is what you did with the
Torque component and the spice project does, which is to split the container
wrapper from the core code.
I may dig in a little on the other containers, but I have a feeling which
ever one we pick will be the wrong one in a years time...
So, to sum up, I am going to plow forward on converting some more of the
core Turbine components in fulcrum. I am going to write some more unit
tests. Try and port the best of Turbine-2 to fulcrum. And any unit tests I
write I may try and put back into Turbine. Then, as soon as we get 2.3 out
of the way we can evaluate which fulcrum components to either move into the
Turbine-2 cvs or to leave in fulcrum, which becomes a repo for avalon
components.
Sound good?
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>Henning,
Hi,
yes. I'm all +1 for this, however I'd prefer to go with some sort of
"turbine-components" repository in the near future. Actually, I
neither like the "fulcrum" name, nor do I think that we should've
opened up another namespace like org.apache.fulcrum.
Before you actually delete code from src/java, please talk with
jmcnally and the other t3 developers/users, I know that they actually
deploy/use Fulcrum and it wouldn't be nice from us (that we don't even
use Fulcrum) to break code that they use.
Personally, I'd prefer org.apache.turbine.components.<componentname>
to make clear that this is really _turbine_ code. For other stuff,
like the quartz scheduler: I wouldn't integrate this into the turbine
repo itself. If this is a component that implements a scheduler and
works in our context without changes: Fine. We put a "3rd party
components that work with Turbine" on the web site, add a link and are
done.
>Did you get a chance to read my follow up email and look at the changes I
>made in Fulcrum? After spending a stack of time trying to understand
>Fulcrum, I think I ended up at the same point you are at, about the Avalon
>components, and ditching the ServiceBroker stuff...
Yes, I'm fine with this. But IMHO this is not really relevant to
Turbine 2.3 but to future stuff. If you have time to work on this,
cool.
>So, in preperation for the post 2.3 future.. Should I continue down the
>path I am? I am happy to slap in a quartz version of the scheduler as well.
>(might throw in the wrapper to my JCrontab one as well ;-) ).
The quartz scheduler has its own home page (don't know where, would
have to look) and I'm fine with where it is. We should work with its
author so it can be used with the AvalonComponentService in 2.3 (hint,
hint. ;-) ) and in further Turbine stuff.
>If we are happy with what I am doing, then I will start deleting code out of
>/src/java and replacing it with the components. My only other question
>though is should all the services become components? And any suggestions on
>order...
Reworking fulcrum is a nice thing, even if all we do in the future is
just salvaging out the good bits. I don't even know whether there are
good bits left. The turbine-2 code has a solid year more work in it,
so it might have actually fallen behind turbine in some aspects.
The reactor build is cool, too (once we get a maven version to be
actually usable with the reactor), but I'd like to still be able to
build the various components separately if only for debugging. If you
want to see an interdependence nightmare, try building a single Avalon
package like "excalibur-component" from source. You will end up with
almost everything from the avalon project checked out and building
before you actually get what you want. I'd like to build a single
component which fetches all of its dependencies from ibiblio.
BTW: I'd prefer that we call jars of the various components broken out
of fulcrum to be called fulcrum-<whatever>-<version>.jar. So there is
clear where they come from.
If you really have time on your hands ;-) , there was some suggestion
on the avalon-dev list, that if we want to use an avalon container
with the AvalonComponentService, ECM might not have been the best
choice. Some developers proposed that we switch to Fortress which
seems to have more advantages and the switch from ECM doesn't seem too
big.
With the rifts that opened inside the Avalon project lately and all
the bad blood going on between the various authors, I'm not sure that
using anything beyond the Avalon Interface stuff would be a wise
decision. I have just skimmed the various discussions but I don't like
the fact that there seems to be no clear idea where to head with
Avalon in the future. There has been even talk about "redoing the
interfaces" and "split up the development", so I don't feel too good
about Avalon currently.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>Henning,
Hi,
yes. I'm all +1 for this, however I'd prefer to go with some sort of
"turbine-components" repository in the near future. Actually, I
neither like the "fulcrum" name, nor do I think that we should've
opened up another namespace like org.apache.fulcrum.
Before you actually delete code from src/java, please talk with
jmcnally and the other t3 developers/users, I know that they actually
deploy/use Fulcrum and it wouldn't be nice from us (that we don't even
use Fulcrum) to break code that they use.
Personally, I'd prefer org.apache.turbine.components.<componentname>
to make clear that this is really _turbine_ code. For other stuff,
like the quartz scheduler: I wouldn't integrate this into the turbine
repo itself. If this is a component that implements a scheduler and
works in our context without changes: Fine. We put a "3rd party
components that work with Turbine" on the web site, add a link and are
done.
>Did you get a chance to read my follow up email and look at the changes I
>made in Fulcrum? After spending a stack of time trying to understand
>Fulcrum, I think I ended up at the same point you are at, about the Avalon
>components, and ditching the ServiceBroker stuff...
Yes, I'm fine with this. But IMHO this is not really relevant to
Turbine 2.3 but to future stuff. If you have time to work on this,
cool.
>So, in preperation for the post 2.3 future.. Should I continue down the
>path I am? I am happy to slap in a quartz version of the scheduler as well.
>(might throw in the wrapper to my JCrontab one as well ;-) ).
The quartz scheduler has its own home page (don't know where, would
have to look) and I'm fine with where it is. We should work with its
author so it can be used with the AvalonComponentService in 2.3 (hint,
hint. ;-) ) and in further Turbine stuff.
>If we are happy with what I am doing, then I will start deleting code out of
>/src/java and replacing it with the components. My only other question
>though is should all the services become components? And any suggestions on
>order...
Reworking fulcrum is a nice thing, even if all we do in the future is
just salvaging out the good bits. I don't even know whether there are
good bits left. The turbine-2 code has a solid year more work in it,
so it might have actually fallen behind turbine in some aspects.
The reactor build is cool, too (once we get a maven version to be
actually usable with the reactor), but I'd like to still be able to
build the various components separately if only for debugging. If you
want to see an interdependence nightmare, try building a single Avalon
package like "excalibur-component" from source. You will end up with
almost everything from the avalon project checked out and building
before you actually get what you want. I'd like to build a single
component which fetches all of its dependencies from ibiblio.
BTW: I'd prefer that we call jars of the various components broken out
of fulcrum to be called fulcrum-<whatever>-<version>.jar. So there is
clear where they come from.
If you really have time on your hands ;-) , there was some suggestion
on the avalon-dev list, that if we want to use an avalon container
with the AvalonComponentService, ECM might not have been the best
choice. Some developers proposed that we switch to Fortress which
seems to have more advantages and the switch from ECM doesn't seem too
big.
With the rifts that opened inside the Avalon project lately and all
the bad blood going on between the various authors, I'm not sure that
using anything beyond the Avalon Interface stuff would be a wise
decision. I have just skimmed the various discussions but I don't like
the fact that there seems to be no clear idea where to head with
Avalon in the future. There has been even talk about "redoing the
interfaces" and "split up the development", so I don't feel too good
about Avalon currently.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by Eric Pugh <ep...@upstate.com>.
Henning,
Did you get a chance to read my follow up email and look at the changes I
made in Fulcrum? After spending a stack of time trying to understand
Fulcrum, I think I ended up at the same point you are at, about the Avalon
components, and ditching the ServiceBroker stuff...
So, in preperation for the post 2.3 future.. Should I continue down the
path I am? I am happy to slap in a quartz version of the scheduler as well.
(might throw in the wrapper to my JCrontab one as well ;-) ).
If we are happy with what I am doing, then I will start deleting code out of
/src/java and replacing it with the components. My only other question
though is should all the services become components? And any suggestions on
order...
Eric
-----Original Message-----
From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
Sent: Sunday, August 17, 2003 3:08 PM
To: turbine-dev@jakarta.apache.org
Subject: Re: [PROPOSAL] Move Torque related classes to seperate turbine
module.
"Eric Pugh" <ep...@upstate.com> writes:
>Hi all,
>I have been watching the large numbers of posts about not being able to
>build Turbine due to the Torque plugin problems. And while granted, it is
>an issue with Maven, I also want to remove the torque jars from my
>project.xml since I don't use Turbine's security or the scheduler service.
>However, this causes problems because Turbine needs Torque, even when you
>don't use it.
Yes. Because we have some unwanted dependencies.
>What is stopping us from removing the security code and scheduler service
>from Turbine, and putting them in Fulcrum's core? Is it because we are
>trying to get to 2.3? Or because no one has tackled the effort? it seems
>that now that Torque has been Avalonized (thanks henning) that we should do
>the same with the components that use Torque.
-1
Turbine 2.3 won't use Fulcrum. Post-2.3, maybe. But then we will
remove much of this dependency anyway.
>I am willing to signup my name next to this, but I need some confirmation
>that this is the path we want, and that we will remove the code from
Turbine
>that is in Fulcrum.
I see a quite different future. I see many of our services being
converted into Avalon-based components and Turbine having some
embedded container to run these services instead of its current
cumbersome ServiceManager / ServiceBroker core.
Personally, I want a clean abstraction of the Security System which
allows really different security concepts like JAAS to be pluggable
into Turbine.
The scheduler service isn't really a needed service, unfortunately it
uses the assembler broker to build it's classes, so we might do some
creative lobotomy here. I repeatedly hear talk about the "Quarz
scheduler" that seems to be an Avalon component so if this works fine
in our future container, well, let's drop the Scheduler Service.
>As an aside, the duplicated code in Turbine and Fulcrum means that in
>Eclipse, when I popup my imports, I am constantly guessing which jar to
>import my classes from, Turbine or Fulcrum!
That's a problem of your IDE. I refuse to start bending the code just
to please a single IDE. If your IDE can't distinguish between classes
from different packages and/or projects, well, start getting another
one.
>On a related note, when can we remove the Criteria object from the
>interfaces for security like UserManager? I would be willing to live with
Yes. Post-2.3. Personally I plan a radically different approach in
slimming down what the Turbine core need from Security Service (which
isn't much) and then retrofit the Security Service to implement just
this interface. After that, you can simply pull Security Service
(which is a mess anyway) out and re-plug a new security concept.
>Criteria just being an Object, not a criteria, and casting it one way in
>DBUserManager, and another way in PassiveUserManager. Heck, then if we had
>HibernateUserManager then the criteria object could be a Hibernate HQL
>query!
Right.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by Eric Pugh <ep...@upstate.com>.
Henning,
Did you get a chance to read my follow up email and look at the changes I
made in Fulcrum? After spending a stack of time trying to understand
Fulcrum, I think I ended up at the same point you are at, about the Avalon
components, and ditching the ServiceBroker stuff...
So, in preperation for the post 2.3 future.. Should I continue down the
path I am? I am happy to slap in a quartz version of the scheduler as well.
(might throw in the wrapper to my JCrontab one as well ;-) ).
If we are happy with what I am doing, then I will start deleting code out of
/src/java and replacing it with the components. My only other question
though is should all the services become components? And any suggestions on
order...
Eric
-----Original Message-----
From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
Sent: Sunday, August 17, 2003 3:08 PM
To: turbine-dev@jakarta.apache.org
Subject: Re: [PROPOSAL] Move Torque related classes to seperate turbine
module.
"Eric Pugh" <ep...@upstate.com> writes:
>Hi all,
>I have been watching the large numbers of posts about not being able to
>build Turbine due to the Torque plugin problems. And while granted, it is
>an issue with Maven, I also want to remove the torque jars from my
>project.xml since I don't use Turbine's security or the scheduler service.
>However, this causes problems because Turbine needs Torque, even when you
>don't use it.
Yes. Because we have some unwanted dependencies.
>What is stopping us from removing the security code and scheduler service
>from Turbine, and putting them in Fulcrum's core? Is it because we are
>trying to get to 2.3? Or because no one has tackled the effort? it seems
>that now that Torque has been Avalonized (thanks henning) that we should do
>the same with the components that use Torque.
-1
Turbine 2.3 won't use Fulcrum. Post-2.3, maybe. But then we will
remove much of this dependency anyway.
>I am willing to signup my name next to this, but I need some confirmation
>that this is the path we want, and that we will remove the code from
Turbine
>that is in Fulcrum.
I see a quite different future. I see many of our services being
converted into Avalon-based components and Turbine having some
embedded container to run these services instead of its current
cumbersome ServiceManager / ServiceBroker core.
Personally, I want a clean abstraction of the Security System which
allows really different security concepts like JAAS to be pluggable
into Turbine.
The scheduler service isn't really a needed service, unfortunately it
uses the assembler broker to build it's classes, so we might do some
creative lobotomy here. I repeatedly hear talk about the "Quarz
scheduler" that seems to be an Avalon component so if this works fine
in our future container, well, let's drop the Scheduler Service.
>As an aside, the duplicated code in Turbine and Fulcrum means that in
>Eclipse, when I popup my imports, I am constantly guessing which jar to
>import my classes from, Turbine or Fulcrum!
That's a problem of your IDE. I refuse to start bending the code just
to please a single IDE. If your IDE can't distinguish between classes
from different packages and/or projects, well, start getting another
one.
>On a related note, when can we remove the Criteria object from the
>interfaces for security like UserManager? I would be willing to live with
Yes. Post-2.3. Personally I plan a radically different approach in
slimming down what the Turbine core need from Security Service (which
isn't much) and then retrofit the Security Service to implement just
this interface. After that, you can simply pull Security Service
(which is a mess anyway) out and re-plug a new security concept.
>Criteria just being an Object, not a criteria, and casting it one way in
>DBUserManager, and another way in PassiveUserManager. Heck, then if we had
>HibernateUserManager then the criteria object could be a Hibernate HQL
>query!
Right.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>Hi all,
>I have been watching the large numbers of posts about not being able to
>build Turbine due to the Torque plugin problems. And while granted, it is
>an issue with Maven, I also want to remove the torque jars from my
>project.xml since I don't use Turbine's security or the scheduler service.
>However, this causes problems because Turbine needs Torque, even when you
>don't use it.
Yes. Because we have some unwanted dependencies.
>What is stopping us from removing the security code and scheduler service
>from Turbine, and putting them in Fulcrum's core? Is it because we are
>trying to get to 2.3? Or because no one has tackled the effort? it seems
>that now that Torque has been Avalonized (thanks henning) that we should do
>the same with the components that use Torque.
-1
Turbine 2.3 won't use Fulcrum. Post-2.3, maybe. But then we will
remove much of this dependency anyway.
>I am willing to signup my name next to this, but I need some confirmation
>that this is the path we want, and that we will remove the code from Turbine
>that is in Fulcrum.
I see a quite different future. I see many of our services being
converted into Avalon-based components and Turbine having some
embedded container to run these services instead of its current
cumbersome ServiceManager / ServiceBroker core.
Personally, I want a clean abstraction of the Security System which
allows really different security concepts like JAAS to be pluggable
into Turbine.
The scheduler service isn't really a needed service, unfortunately it
uses the assembler broker to build it's classes, so we might do some
creative lobotomy here. I repeatedly hear talk about the "Quarz
scheduler" that seems to be an Avalon component so if this works fine
in our future container, well, let's drop the Scheduler Service.
>As an aside, the duplicated code in Turbine and Fulcrum means that in
>Eclipse, when I popup my imports, I am constantly guessing which jar to
>import my classes from, Turbine or Fulcrum!
That's a problem of your IDE. I refuse to start bending the code just
to please a single IDE. If your IDE can't distinguish between classes
from different packages and/or projects, well, start getting another
one.
>On a related note, when can we remove the Criteria object from the
>interfaces for security like UserManager? I would be willing to live with
Yes. Post-2.3. Personally I plan a radically different approach in
slimming down what the Turbine core need from Security Service (which
isn't much) and then retrofit the Security Service to implement just
this interface. After that, you can simply pull Security Service
(which is a mess anyway) out and re-plug a new security concept.
>Criteria just being an Object, not a criteria, and casting it one way in
>DBUserManager, and another way in PassiveUserManager. Heck, then if we had
>HibernateUserManager then the criteria object could be a Hibernate HQL
>query!
Right.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>Hi all,
>I have been watching the large numbers of posts about not being able to
>build Turbine due to the Torque plugin problems. And while granted, it is
>an issue with Maven, I also want to remove the torque jars from my
>project.xml since I don't use Turbine's security or the scheduler service.
>However, this causes problems because Turbine needs Torque, even when you
>don't use it.
Yes. Because we have some unwanted dependencies.
>What is stopping us from removing the security code and scheduler service
>from Turbine, and putting them in Fulcrum's core? Is it because we are
>trying to get to 2.3? Or because no one has tackled the effort? it seems
>that now that Torque has been Avalonized (thanks henning) that we should do
>the same with the components that use Torque.
-1
Turbine 2.3 won't use Fulcrum. Post-2.3, maybe. But then we will
remove much of this dependency anyway.
>I am willing to signup my name next to this, but I need some confirmation
>that this is the path we want, and that we will remove the code from Turbine
>that is in Fulcrum.
I see a quite different future. I see many of our services being
converted into Avalon-based components and Turbine having some
embedded container to run these services instead of its current
cumbersome ServiceManager / ServiceBroker core.
Personally, I want a clean abstraction of the Security System which
allows really different security concepts like JAAS to be pluggable
into Turbine.
The scheduler service isn't really a needed service, unfortunately it
uses the assembler broker to build it's classes, so we might do some
creative lobotomy here. I repeatedly hear talk about the "Quarz
scheduler" that seems to be an Avalon component so if this works fine
in our future container, well, let's drop the Scheduler Service.
>As an aside, the duplicated code in Turbine and Fulcrum means that in
>Eclipse, when I popup my imports, I am constantly guessing which jar to
>import my classes from, Turbine or Fulcrum!
That's a problem of your IDE. I refuse to start bending the code just
to please a single IDE. If your IDE can't distinguish between classes
from different packages and/or projects, well, start getting another
one.
>On a related note, when can we remove the Criteria object from the
>interfaces for security like UserManager? I would be willing to live with
Yes. Post-2.3. Personally I plan a radically different approach in
slimming down what the Turbine core need from Security Service (which
isn't much) and then retrofit the Security Service to implement just
this interface. After that, you can simply pull Security Service
(which is a mess anyway) out and re-plug a new security concept.
>Criteria just being an Object, not a criteria, and casting it one way in
>DBUserManager, and another way in PassiveUserManager. Heck, then if we had
>HibernateUserManager then the criteria object could be a Hibernate HQL
>query!
Right.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
[FULCRUM] Migrate Fulcrum components to Avalon... WAS [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I did a fresh checkout of Fulcrum.. And there are errors all over the
place.. I am somewhat of the opinion that if we can make the consensus that
using components via Avalon is the way forward, then we should delete all
the components that don't compile in Fulcrum, and then start moving
components over from Turbine-2 as a fresh start. While is seems like all
the code in /src/ is some what trashed, it seems like someone (Quinton?) was
setting Fulcrum up to use the maven reactor setup, because there are /pull,
/testcontainer, and /xmlrpc subprojects.
This follows somewhat the pattern of the Xingu project that uses a reactor
to build each component. It means you have lots of little jars, and seems
to help with breaking up all the components, so that Fulcrum doesn't end up
as one "super build"...
To see where this would lead me, I converted the various components that had
unit tests into reactor driven subprojects.
Converted:
/dvsl
/localization
/crypto
I was basically following the style that Quinton established with
testcomponent, pull, and xmlrpc. I fixed a stack of small bugs with those
as well. The whole fulcrum container with the whacky
ServiceBroker/ServiceManager stuff brought over from Turbine core I just
couldn't figure out. So, at this point there are now 5 components that run
as Avalon components, and don't have any dependencies on Turbine. I ended
up not converting the Facade classes for dvsl, localization, and crypto, as
I just could not get my head around them.
To see the build happen, from jakarta-turbine-fulcrum/ run maven build to
see the reactor work. For some reason the reactor can't build the docs, but
you can from each individual directory.
I think this is a viable path forward. I think getting anything that works
in Fulcrum is miles better then the current amazingly sophicsticated and
amazingly broken, hard to grok code in /src/java and /src/test.
I don't know what the deprecation rules are.. But I can't imagine anyone is
successfully using Fulcrum, at least judging by the state of CVS head.
Any feed back would be much appreciated...
Sincerely,
Eric Pugh
-----Original Message-----
From: Eric Pugh [mailto:epugh@upstate.com]
Sent: Friday, August 15, 2003 11:34 PM
To: 'Turbine Developers List'
Subject: RE: [PROPOSAL] Move Torque related classes to seperate
turbinemodule.
I think though that the shortterm path needs to be removing all the
extranous service from Turbine, and getting them all to run as Avalon
components in the Fulcrum cvs...
I think we talked about this a while ago, but it kinda fell by the wayside..
Eric
-----Original Message-----
From: Leandro Rodrigo Saad Cruz [mailto:leandro@ibnetwork.com.br]
Sent: Friday, August 15, 2003 2:25 PM
To: turbine-dev@jakarta.apache.org
Cc: epugh@upstate.com
Subject: Re: [PROPOSAL] Move Torque related classes to seperate
turbinemodule.
Not a commiter, but here goes my +1.
I think turbine should concentrate on routing the process to fulfill the
request (Say, using the pipeline metaphore, request dispatcher, etc) and
provide a configurable container for components using an arbitrary
component model, ala Avalon.
The basic configuration should support today's turbine specification
(http://jakarta.apache.org/turbine/fsd.html)
This is much easier to customize and extend. Do you want a JMX enabled
container ? you can ! Do you want another scheduler ? you can ! Do you
want another user manager ? you can have it..
Basically the Turbine servlet would initialize the container, the
pipelines, etc and route the requests through the right pipeline.
The pipeline manager itself could be a component inside the container.
The same goes to the request dispatcher, etc !
I've never worked with T3, but I think that was the general idea, and I
think it was right, but all services on fulcrum could only be used on
turbine+fulcrum (not sure). I think all components developed to be
pluged into turbine should be used by other applications too !
On Fri, 2003-08-15 at 08:59, Eric Pugh wrote:
> Hi all,
>
> I have been watching the large numbers of posts about not being able to
> build Turbine due to the Torque plugin problems. And while granted, it is
> an issue with Maven, I also want to remove the torque jars from my
> project.xml since I don't use Turbine's security or the scheduler service.
> However, this causes problems because Turbine needs Torque, even when you
> don't use it.
>
> What is stopping us from removing the security code and scheduler service
> from Turbine, and putting them in Fulcrum's core? Is it because we are
> trying to get to 2.3? Or because no one has tackled the effort? it seems
> that now that Torque has been Avalonized (thanks henning) that we should
do
> the same with the components that use Torque.
>
> I am willing to signup my name next to this, but I need some confirmation
> that this is the path we want, and that we will remove the code from
Turbine
> that is in Fulcrum.
>
> As an aside, the duplicated code in Turbine and Fulcrum means that in
> Eclipse, when I popup my imports, I am constantly guessing which jar to
> import my classes from, Turbine or Fulcrum!
>
> On a related note, when can we remove the Criteria object from the
> interfaces for security like UserManager? I would be willing to live with
> Criteria just being an Object, not a criteria, and casting it one way in
> DBUserManager, and another way in PassiveUserManager. Heck, then if we
had
> HibernateUserManager then the criteria object could be a Hibernate HQL
> query!
>
> Frustrated with polluted interfaces,
> Eric Pugh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
[FULCRUM] Migrate Fulcrum components to Avalon... WAS [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I did a fresh checkout of Fulcrum.. And there are errors all over the
place.. I am somewhat of the opinion that if we can make the consensus that
using components via Avalon is the way forward, then we should delete all
the components that don't compile in Fulcrum, and then start moving
components over from Turbine-2 as a fresh start. While is seems like all
the code in /src/ is some what trashed, it seems like someone (Quinton?) was
setting Fulcrum up to use the maven reactor setup, because there are /pull,
/testcontainer, and /xmlrpc subprojects.
This follows somewhat the pattern of the Xingu project that uses a reactor
to build each component. It means you have lots of little jars, and seems
to help with breaking up all the components, so that Fulcrum doesn't end up
as one "super build"...
To see where this would lead me, I converted the various components that had
unit tests into reactor driven subprojects.
Converted:
/dvsl
/localization
/crypto
I was basically following the style that Quinton established with
testcomponent, pull, and xmlrpc. I fixed a stack of small bugs with those
as well. The whole fulcrum container with the whacky
ServiceBroker/ServiceManager stuff brought over from Turbine core I just
couldn't figure out. So, at this point there are now 5 components that run
as Avalon components, and don't have any dependencies on Turbine. I ended
up not converting the Facade classes for dvsl, localization, and crypto, as
I just could not get my head around them.
To see the build happen, from jakarta-turbine-fulcrum/ run maven build to
see the reactor work. For some reason the reactor can't build the docs, but
you can from each individual directory.
I think this is a viable path forward. I think getting anything that works
in Fulcrum is miles better then the current amazingly sophicsticated and
amazingly broken, hard to grok code in /src/java and /src/test.
I don't know what the deprecation rules are.. But I can't imagine anyone is
successfully using Fulcrum, at least judging by the state of CVS head.
Any feed back would be much appreciated...
Sincerely,
Eric Pugh
-----Original Message-----
From: Eric Pugh [mailto:epugh@upstate.com]
Sent: Friday, August 15, 2003 11:34 PM
To: 'Turbine Developers List'
Subject: RE: [PROPOSAL] Move Torque related classes to seperate
turbinemodule.
I think though that the shortterm path needs to be removing all the
extranous service from Turbine, and getting them all to run as Avalon
components in the Fulcrum cvs...
I think we talked about this a while ago, but it kinda fell by the wayside..
Eric
-----Original Message-----
From: Leandro Rodrigo Saad Cruz [mailto:leandro@ibnetwork.com.br]
Sent: Friday, August 15, 2003 2:25 PM
To: turbine-dev@jakarta.apache.org
Cc: epugh@upstate.com
Subject: Re: [PROPOSAL] Move Torque related classes to seperate
turbinemodule.
Not a commiter, but here goes my +1.
I think turbine should concentrate on routing the process to fulfill the
request (Say, using the pipeline metaphore, request dispatcher, etc) and
provide a configurable container for components using an arbitrary
component model, ala Avalon.
The basic configuration should support today's turbine specification
(http://jakarta.apache.org/turbine/fsd.html)
This is much easier to customize and extend. Do you want a JMX enabled
container ? you can ! Do you want another scheduler ? you can ! Do you
want another user manager ? you can have it..
Basically the Turbine servlet would initialize the container, the
pipelines, etc and route the requests through the right pipeline.
The pipeline manager itself could be a component inside the container.
The same goes to the request dispatcher, etc !
I've never worked with T3, but I think that was the general idea, and I
think it was right, but all services on fulcrum could only be used on
turbine+fulcrum (not sure). I think all components developed to be
pluged into turbine should be used by other applications too !
On Fri, 2003-08-15 at 08:59, Eric Pugh wrote:
> Hi all,
>
> I have been watching the large numbers of posts about not being able to
> build Turbine due to the Torque plugin problems. And while granted, it is
> an issue with Maven, I also want to remove the torque jars from my
> project.xml since I don't use Turbine's security or the scheduler service.
> However, this causes problems because Turbine needs Torque, even when you
> don't use it.
>
> What is stopping us from removing the security code and scheduler service
> from Turbine, and putting them in Fulcrum's core? Is it because we are
> trying to get to 2.3? Or because no one has tackled the effort? it seems
> that now that Torque has been Avalonized (thanks henning) that we should
do
> the same with the components that use Torque.
>
> I am willing to signup my name next to this, but I need some confirmation
> that this is the path we want, and that we will remove the code from
Turbine
> that is in Fulcrum.
>
> As an aside, the duplicated code in Turbine and Fulcrum means that in
> Eclipse, when I popup my imports, I am constantly guessing which jar to
> import my classes from, Turbine or Fulcrum!
>
> On a related note, when can we remove the Criteria object from the
> interfaces for security like UserManager? I would be willing to live with
> Criteria just being an Object, not a criteria, and casting it one way in
> DBUserManager, and another way in PassiveUserManager. Heck, then if we
had
> HibernateUserManager then the criteria object could be a Hibernate HQL
> query!
>
> Frustrated with polluted interfaces,
> Eric Pugh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [PROPOSAL] Move Torque related classes to seperate turbinemodule.
Posted by Eric Pugh <ep...@upstate.com>.
I think though that the shortterm path needs to be removing all the
extranous service from Turbine, and getting them all to run as Avalon
components in the Fulcrum cvs...
I think we talked about this a while ago, but it kinda fell by the wayside..
Eric
-----Original Message-----
From: Leandro Rodrigo Saad Cruz [mailto:leandro@ibnetwork.com.br]
Sent: Friday, August 15, 2003 2:25 PM
To: turbine-dev@jakarta.apache.org
Cc: epugh@upstate.com
Subject: Re: [PROPOSAL] Move Torque related classes to seperate
turbinemodule.
Not a commiter, but here goes my +1.
I think turbine should concentrate on routing the process to fulfill the
request (Say, using the pipeline metaphore, request dispatcher, etc) and
provide a configurable container for components using an arbitrary
component model, ala Avalon.
The basic configuration should support today's turbine specification
(http://jakarta.apache.org/turbine/fsd.html)
This is much easier to customize and extend. Do you want a JMX enabled
container ? you can ! Do you want another scheduler ? you can ! Do you
want another user manager ? you can have it..
Basically the Turbine servlet would initialize the container, the
pipelines, etc and route the requests through the right pipeline.
The pipeline manager itself could be a component inside the container.
The same goes to the request dispatcher, etc !
I've never worked with T3, but I think that was the general idea, and I
think it was right, but all services on fulcrum could only be used on
turbine+fulcrum (not sure). I think all components developed to be
pluged into turbine should be used by other applications too !
On Fri, 2003-08-15 at 08:59, Eric Pugh wrote:
> Hi all,
>
> I have been watching the large numbers of posts about not being able to
> build Turbine due to the Torque plugin problems. And while granted, it is
> an issue with Maven, I also want to remove the torque jars from my
> project.xml since I don't use Turbine's security or the scheduler service.
> However, this causes problems because Turbine needs Torque, even when you
> don't use it.
>
> What is stopping us from removing the security code and scheduler service
> from Turbine, and putting them in Fulcrum's core? Is it because we are
> trying to get to 2.3? Or because no one has tackled the effort? it seems
> that now that Torque has been Avalonized (thanks henning) that we should
do
> the same with the components that use Torque.
>
> I am willing to signup my name next to this, but I need some confirmation
> that this is the path we want, and that we will remove the code from
Turbine
> that is in Fulcrum.
>
> As an aside, the duplicated code in Turbine and Fulcrum means that in
> Eclipse, when I popup my imports, I am constantly guessing which jar to
> import my classes from, Turbine or Fulcrum!
>
> On a related note, when can we remove the Criteria object from the
> interfaces for security like UserManager? I would be willing to live with
> Criteria just being an Object, not a criteria, and casting it one way in
> DBUserManager, and another way in PassiveUserManager. Heck, then if we
had
> HibernateUserManager then the criteria object could be a Hibernate HQL
> query!
>
> Frustrated with polluted interfaces,
> Eric Pugh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [PROPOSAL] Move Torque related classes to seperate turbinemodule.
Posted by Eric Pugh <ep...@upstate.com>.
I think though that the shortterm path needs to be removing all the
extranous service from Turbine, and getting them all to run as Avalon
components in the Fulcrum cvs...
I think we talked about this a while ago, but it kinda fell by the wayside..
Eric
-----Original Message-----
From: Leandro Rodrigo Saad Cruz [mailto:leandro@ibnetwork.com.br]
Sent: Friday, August 15, 2003 2:25 PM
To: turbine-dev@jakarta.apache.org
Cc: epugh@upstate.com
Subject: Re: [PROPOSAL] Move Torque related classes to seperate
turbinemodule.
Not a commiter, but here goes my +1.
I think turbine should concentrate on routing the process to fulfill the
request (Say, using the pipeline metaphore, request dispatcher, etc) and
provide a configurable container for components using an arbitrary
component model, ala Avalon.
The basic configuration should support today's turbine specification
(http://jakarta.apache.org/turbine/fsd.html)
This is much easier to customize and extend. Do you want a JMX enabled
container ? you can ! Do you want another scheduler ? you can ! Do you
want another user manager ? you can have it..
Basically the Turbine servlet would initialize the container, the
pipelines, etc and route the requests through the right pipeline.
The pipeline manager itself could be a component inside the container.
The same goes to the request dispatcher, etc !
I've never worked with T3, but I think that was the general idea, and I
think it was right, but all services on fulcrum could only be used on
turbine+fulcrum (not sure). I think all components developed to be
pluged into turbine should be used by other applications too !
On Fri, 2003-08-15 at 08:59, Eric Pugh wrote:
> Hi all,
>
> I have been watching the large numbers of posts about not being able to
> build Turbine due to the Torque plugin problems. And while granted, it is
> an issue with Maven, I also want to remove the torque jars from my
> project.xml since I don't use Turbine's security or the scheduler service.
> However, this causes problems because Turbine needs Torque, even when you
> don't use it.
>
> What is stopping us from removing the security code and scheduler service
> from Turbine, and putting them in Fulcrum's core? Is it because we are
> trying to get to 2.3? Or because no one has tackled the effort? it seems
> that now that Torque has been Avalonized (thanks henning) that we should
do
> the same with the components that use Torque.
>
> I am willing to signup my name next to this, but I need some confirmation
> that this is the path we want, and that we will remove the code from
Turbine
> that is in Fulcrum.
>
> As an aside, the duplicated code in Turbine and Fulcrum means that in
> Eclipse, when I popup my imports, I am constantly guessing which jar to
> import my classes from, Turbine or Fulcrum!
>
> On a related note, when can we remove the Criteria object from the
> interfaces for security like UserManager? I would be willing to live with
> Criteria just being an Object, not a criteria, and casting it one way in
> DBUserManager, and another way in PassiveUserManager. Heck, then if we
had
> HibernateUserManager then the criteria object could be a Hibernate HQL
> query!
>
> Frustrated with polluted interfaces,
> Eric Pugh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PROPOSAL] Move Torque related classes to seperate turbine
module.
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
Not a commiter, but here goes my +1.
I think turbine should concentrate on routing the process to fulfill the
request (Say, using the pipeline metaphore, request dispatcher, etc) and
provide a configurable container for components using an arbitrary
component model, ala Avalon.
The basic configuration should support today's turbine specification
(http://jakarta.apache.org/turbine/fsd.html)
This is much easier to customize and extend. Do you want a JMX enabled
container ? you can ! Do you want another scheduler ? you can ! Do you
want another user manager ? you can have it..
Basically the Turbine servlet would initialize the container, the
pipelines, etc and route the requests through the right pipeline.
The pipeline manager itself could be a component inside the container.
The same goes to the request dispatcher, etc !
I've never worked with T3, but I think that was the general idea, and I
think it was right, but all services on fulcrum could only be used on
turbine+fulcrum (not sure). I think all components developed to be
pluged into turbine should be used by other applications too !
On Fri, 2003-08-15 at 08:59, Eric Pugh wrote:
> Hi all,
>
> I have been watching the large numbers of posts about not being able to
> build Turbine due to the Torque plugin problems. And while granted, it is
> an issue with Maven, I also want to remove the torque jars from my
> project.xml since I don't use Turbine's security or the scheduler service.
> However, this causes problems because Turbine needs Torque, even when you
> don't use it.
>
> What is stopping us from removing the security code and scheduler service
> from Turbine, and putting them in Fulcrum's core? Is it because we are
> trying to get to 2.3? Or because no one has tackled the effort? it seems
> that now that Torque has been Avalonized (thanks henning) that we should do
> the same with the components that use Torque.
>
> I am willing to signup my name next to this, but I need some confirmation
> that this is the path we want, and that we will remove the code from Turbine
> that is in Fulcrum.
>
> As an aside, the duplicated code in Turbine and Fulcrum means that in
> Eclipse, when I popup my imports, I am constantly guessing which jar to
> import my classes from, Turbine or Fulcrum!
>
> On a related note, when can we remove the Criteria object from the
> interfaces for security like UserManager? I would be willing to live with
> Criteria just being an Object, not a criteria, and casting it one way in
> DBUserManager, and another way in PassiveUserManager. Heck, then if we had
> HibernateUserManager then the criteria object could be a Hibernate HQL
> query!
>
> Frustrated with polluted interfaces,
> Eric Pugh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PROPOSAL] Move Torque related classes to seperate turbine
module.
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
Not a commiter, but here goes my +1.
I think turbine should concentrate on routing the process to fulfill the
request (Say, using the pipeline metaphore, request dispatcher, etc) and
provide a configurable container for components using an arbitrary
component model, ala Avalon.
The basic configuration should support today's turbine specification
(http://jakarta.apache.org/turbine/fsd.html)
This is much easier to customize and extend. Do you want a JMX enabled
container ? you can ! Do you want another scheduler ? you can ! Do you
want another user manager ? you can have it..
Basically the Turbine servlet would initialize the container, the
pipelines, etc and route the requests through the right pipeline.
The pipeline manager itself could be a component inside the container.
The same goes to the request dispatcher, etc !
I've never worked with T3, but I think that was the general idea, and I
think it was right, but all services on fulcrum could only be used on
turbine+fulcrum (not sure). I think all components developed to be
pluged into turbine should be used by other applications too !
On Fri, 2003-08-15 at 08:59, Eric Pugh wrote:
> Hi all,
>
> I have been watching the large numbers of posts about not being able to
> build Turbine due to the Torque plugin problems. And while granted, it is
> an issue with Maven, I also want to remove the torque jars from my
> project.xml since I don't use Turbine's security or the scheduler service.
> However, this causes problems because Turbine needs Torque, even when you
> don't use it.
>
> What is stopping us from removing the security code and scheduler service
> from Turbine, and putting them in Fulcrum's core? Is it because we are
> trying to get to 2.3? Or because no one has tackled the effort? it seems
> that now that Torque has been Avalonized (thanks henning) that we should do
> the same with the components that use Torque.
>
> I am willing to signup my name next to this, but I need some confirmation
> that this is the path we want, and that we will remove the code from Turbine
> that is in Fulcrum.
>
> As an aside, the duplicated code in Turbine and Fulcrum means that in
> Eclipse, when I popup my imports, I am constantly guessing which jar to
> import my classes from, Turbine or Fulcrum!
>
> On a related note, when can we remove the Criteria object from the
> interfaces for security like UserManager? I would be willing to live with
> Criteria just being an Object, not a criteria, and casting it one way in
> DBUserManager, and another way in PassiveUserManager. Heck, then if we had
> HibernateUserManager then the criteria object could be a Hibernate HQL
> query!
>
> Frustrated with polluted interfaces,
> Eric Pugh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sourceforge.net
[PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I have been watching the large numbers of posts about not being able to
build Turbine due to the Torque plugin problems. And while granted, it is
an issue with Maven, I also want to remove the torque jars from my
project.xml since I don't use Turbine's security or the scheduler service.
However, this causes problems because Turbine needs Torque, even when you
don't use it.
What is stopping us from removing the security code and scheduler service
from Turbine, and putting them in Fulcrum's core? Is it because we are
trying to get to 2.3? Or because no one has tackled the effort? it seems
that now that Torque has been Avalonized (thanks henning) that we should do
the same with the components that use Torque.
I am willing to signup my name next to this, but I need some confirmation
that this is the path we want, and that we will remove the code from Turbine
that is in Fulcrum.
As an aside, the duplicated code in Turbine and Fulcrum means that in
Eclipse, when I popup my imports, I am constantly guessing which jar to
import my classes from, Turbine or Fulcrum!
On a related note, when can we remove the Criteria object from the
interfaces for security like UserManager? I would be willing to live with
Criteria just being an Object, not a criteria, and casting it one way in
DBUserManager, and another way in PassiveUserManager. Heck, then if we had
HibernateUserManager then the criteria object could be a Hibernate HQL
query!
Frustrated with polluted interfaces,
Eric Pugh
[PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I have been watching the large numbers of posts about not being able to
build Turbine due to the Torque plugin problems. And while granted, it is
an issue with Maven, I also want to remove the torque jars from my
project.xml since I don't use Turbine's security or the scheduler service.
However, this causes problems because Turbine needs Torque, even when you
don't use it.
What is stopping us from removing the security code and scheduler service
from Turbine, and putting them in Fulcrum's core? Is it because we are
trying to get to 2.3? Or because no one has tackled the effort? it seems
that now that Torque has been Avalonized (thanks henning) that we should do
the same with the components that use Torque.
I am willing to signup my name next to this, but I need some confirmation
that this is the path we want, and that we will remove the code from Turbine
that is in Fulcrum.
As an aside, the duplicated code in Turbine and Fulcrum means that in
Eclipse, when I popup my imports, I am constantly guessing which jar to
import my classes from, Turbine or Fulcrum!
On a related note, when can we remove the Criteria object from the
interfaces for security like UserManager? I would be willing to live with
Criteria just being an Object, not a criteria, and casting it one way in
DBUserManager, and another way in PassiveUserManager. Heck, then if we had
HibernateUserManager then the criteria object could be a Hibernate HQL
query!
Frustrated with polluted interfaces,
Eric Pugh
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Can we delete RunDataFactory?
Posted by Eric Pugh <ep...@upstate.com>.
I wouldn't say that we are goign to delete it quite yet, but the "non
deprecated" approved way is to replace it with this:
data = ((RunDataService)
TurbineServices.getInstance().getService(RunDataService.SERVICE_NAME)).getRu
nData(request, response, config);
context = TurbineVelocity.getContext(data);
At least, that works if you are testing in a Cactus type environment.
However, thanks for bringing up the documentation on the wiki. I will
update it!
Eric Pugh
-----Original Message-----
From: Jürgen Hoffmann [mailto:jh@byteaction.de]
Sent: Thursday, August 14, 2003 10:06 AM
To: 'Turbine Developers List'; epugh@upstate.com
Subject: AW: Can we delete RunDataFactory?
Hi,
We are using RunDataFactory to test our actions, as explained in
http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaTurbine2Faq if this
is going to be deleted, is there going to be another way to test Turbine
Actions?
Kind regards
Jürgen Hoffmann
-----Ursprüngliche Nachricht-----
Von: Eric Pugh [mailto:epugh@upstate.com]
Gesendet: Mittwoch, 13. August 2003 00:45
An: 'Turbine Developers List'
Betreff: Can we delete RunDataFactory?
Hi all,
I noticed that RunDataFactory is really old. Notice this comment: //
NOTE: getRunData( HttpServletRequest req,
// HttpServletResponse res ) has been deprecated 3-3-2000.
// Wait a couple months (before Turbine 1.0) and remove this
// method.
I don't mind doing the work, but I think we should remove it as 1.0 has
been out a bit...
:-)
Eric
-----Original Message-----
From: Eric Emminger [mailto:eric@ericemminger.com]
Sent: Monday, August 11, 2003 5:39 PM
To: Turbine Developers List
Subject: Re: Reg: Error Occurred in Ohioedge CRM.
Velmurugan (Java) wrote:
> Hi All,
>
> When we run the application called "Ohioedge CRM" and got the
> following
error. Kindly help us how to trace out the solutions.I have followed all
the instrunctions which are given in installation document.
>
> Software's used.
> =============
>
> 1. JDK1.4.1
> 2. JBoss-3.2.1
>
> Platform
> =======
>
> Win-2K Professional.
>
>
> ERROR
>
========================================================================
====
==================
>
> 2003-08-09 14:54:46,363 INFO [STDOUT] 1304306 [Thread-44] DEBUG
org.apache.torque.oid.IDBroker - IDBroker thread was started.
> 2003-08-09 14:54:48,365 WARN [org.apache.torque.oid.IDBroker]
> IDBroker is
being used with db 'default', which does not support transactions.
IDBroker attempts to use transactions to limit the possibility of
duplicate key generation. Without transactions, duplicate key
generation is possible if multiple JVMs are used or other means are used
to write to the database.
> 2003-08-09 14:54:48,375 INFO [STDOUT] 1306308 [PoolThread-9] WARN
org.apache.torque.oid.IDBroker - IDBroker is being used with db
'default', which does not support transactions. IDBroker attempts to use
transactions to limit the possibility of duplicate key generation.
Without transactions, duplicate key generation is possible if multiple
JVMs are used or other means are used to write to the database.
> 2003-08-09 14:54:50,368 ERROR [org.apache.torque.util.BasePeer]
org.apache.torque.TorqueException: Connection is broken: Connection
refused: connect
This is probably the real problem. Torque is unable to connect to your
database. Make sure you've configured your Ohioedge CRM application
correctly, which may involve configuring Torque. If you need help with
Torque, see the Torque site which is now at http://db.apache.org/torque/
Otherwise, you may need to contact Ohioedge.
> 2003-08-09 14:54:50,378 INFO [STDOUT] 1308311 [PoolThread-9] ERROR
org.apache.torque.util.BasePeer - org.apache.torque.TorqueException:
Connection is broken: Connection refused: connect
> 2003-08-09 14:54:50,388 ERROR [org.apache.torque.util.BasePeer] A
> FATAL
ERROR has occurred which should not have happened under any
circumstance. Please notify the Turbine developers
<tu...@jakarta.apache.org> and give as many details as possible
(including the error stack trace).
> java.lang.Error: Error in BasePeer.initTableSchema(TURBINE_USER):
Connection is broken: Connection refused: connect
I'm fairly sure your problem is NOT with Turbine.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Can we delete RunDataFactory?
Posted by Eric Pugh <ep...@upstate.com>.
I wouldn't say that we are goign to delete it quite yet, but the "non
deprecated" approved way is to replace it with this:
data = ((RunDataService)
TurbineServices.getInstance().getService(RunDataService.SERVICE_NAME)).getRu
nData(request, response, config);
context = TurbineVelocity.getContext(data);
At least, that works if you are testing in a Cactus type environment.
However, thanks for bringing up the documentation on the wiki. I will
update it!
Eric Pugh
-----Original Message-----
From: Jürgen Hoffmann [mailto:jh@byteaction.de]
Sent: Thursday, August 14, 2003 10:06 AM
To: 'Turbine Developers List'; epugh@upstate.com
Subject: AW: Can we delete RunDataFactory?
Hi,
We are using RunDataFactory to test our actions, as explained in
http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaTurbine2Faq if this
is going to be deleted, is there going to be another way to test Turbine
Actions?
Kind regards
Jürgen Hoffmann
-----Ursprüngliche Nachricht-----
Von: Eric Pugh [mailto:epugh@upstate.com]
Gesendet: Mittwoch, 13. August 2003 00:45
An: 'Turbine Developers List'
Betreff: Can we delete RunDataFactory?
Hi all,
I noticed that RunDataFactory is really old. Notice this comment: //
NOTE: getRunData( HttpServletRequest req,
// HttpServletResponse res ) has been deprecated 3-3-2000.
// Wait a couple months (before Turbine 1.0) and remove this
// method.
I don't mind doing the work, but I think we should remove it as 1.0 has
been out a bit...
:-)
Eric
-----Original Message-----
From: Eric Emminger [mailto:eric@ericemminger.com]
Sent: Monday, August 11, 2003 5:39 PM
To: Turbine Developers List
Subject: Re: Reg: Error Occurred in Ohioedge CRM.
Velmurugan (Java) wrote:
> Hi All,
>
> When we run the application called "Ohioedge CRM" and got the
> following
error. Kindly help us how to trace out the solutions.I have followed all
the instrunctions which are given in installation document.
>
> Software's used.
> =============
>
> 1. JDK1.4.1
> 2. JBoss-3.2.1
>
> Platform
> =======
>
> Win-2K Professional.
>
>
> ERROR
>
========================================================================
====
==================
>
> 2003-08-09 14:54:46,363 INFO [STDOUT] 1304306 [Thread-44] DEBUG
org.apache.torque.oid.IDBroker - IDBroker thread was started.
> 2003-08-09 14:54:48,365 WARN [org.apache.torque.oid.IDBroker]
> IDBroker is
being used with db 'default', which does not support transactions.
IDBroker attempts to use transactions to limit the possibility of
duplicate key generation. Without transactions, duplicate key
generation is possible if multiple JVMs are used or other means are used
to write to the database.
> 2003-08-09 14:54:48,375 INFO [STDOUT] 1306308 [PoolThread-9] WARN
org.apache.torque.oid.IDBroker - IDBroker is being used with db
'default', which does not support transactions. IDBroker attempts to use
transactions to limit the possibility of duplicate key generation.
Without transactions, duplicate key generation is possible if multiple
JVMs are used or other means are used to write to the database.
> 2003-08-09 14:54:50,368 ERROR [org.apache.torque.util.BasePeer]
org.apache.torque.TorqueException: Connection is broken: Connection
refused: connect
This is probably the real problem. Torque is unable to connect to your
database. Make sure you've configured your Ohioedge CRM application
correctly, which may involve configuring Torque. If you need help with
Torque, see the Torque site which is now at http://db.apache.org/torque/
Otherwise, you may need to contact Ohioedge.
> 2003-08-09 14:54:50,378 INFO [STDOUT] 1308311 [PoolThread-9] ERROR
org.apache.torque.util.BasePeer - org.apache.torque.TorqueException:
Connection is broken: Connection refused: connect
> 2003-08-09 14:54:50,388 ERROR [org.apache.torque.util.BasePeer] A
> FATAL
ERROR has occurred which should not have happened under any
circumstance. Please notify the Turbine developers
<tu...@jakarta.apache.org> and give as many details as possible
(including the error stack trace).
> java.lang.Error: Error in BasePeer.initTableSchema(TURBINE_USER):
Connection is broken: Connection refused: connect
I'm fairly sure your problem is NOT with Turbine.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
AW: Can we delete RunDataFactory?
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi,
We are using RunDataFactory to test our actions, as explained in
http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaTurbine2Faq if this
is going to be deleted, is there going to be another way to test Turbine
Actions?
Kind regards
Jürgen Hoffmann
-----Ursprüngliche Nachricht-----
Von: Eric Pugh [mailto:epugh@upstate.com]
Gesendet: Mittwoch, 13. August 2003 00:45
An: 'Turbine Developers List'
Betreff: Can we delete RunDataFactory?
Hi all,
I noticed that RunDataFactory is really old. Notice this comment: //
NOTE: getRunData( HttpServletRequest req,
// HttpServletResponse res ) has been deprecated 3-3-2000.
// Wait a couple months (before Turbine 1.0) and remove this
// method.
I don't mind doing the work, but I think we should remove it as 1.0 has
been out a bit...
:-)
Eric
-----Original Message-----
From: Eric Emminger [mailto:eric@ericemminger.com]
Sent: Monday, August 11, 2003 5:39 PM
To: Turbine Developers List
Subject: Re: Reg: Error Occurred in Ohioedge CRM.
Velmurugan (Java) wrote:
> Hi All,
>
> When we run the application called "Ohioedge CRM" and got the
> following
error. Kindly help us how to trace out the solutions.I have followed all
the instrunctions which are given in installation document.
>
> Software's used.
> =============
>
> 1. JDK1.4.1
> 2. JBoss-3.2.1
>
> Platform
> =======
>
> Win-2K Professional.
>
>
> ERROR
>
========================================================================
====
==================
>
> 2003-08-09 14:54:46,363 INFO [STDOUT] 1304306 [Thread-44] DEBUG
org.apache.torque.oid.IDBroker - IDBroker thread was started.
> 2003-08-09 14:54:48,365 WARN [org.apache.torque.oid.IDBroker]
> IDBroker is
being used with db 'default', which does not support transactions.
IDBroker attempts to use transactions to limit the possibility of
duplicate key generation. Without transactions, duplicate key
generation is possible if multiple JVMs are used or other means are used
to write to the database.
> 2003-08-09 14:54:48,375 INFO [STDOUT] 1306308 [PoolThread-9] WARN
org.apache.torque.oid.IDBroker - IDBroker is being used with db
'default', which does not support transactions. IDBroker attempts to use
transactions to limit the possibility of duplicate key generation.
Without transactions, duplicate key generation is possible if multiple
JVMs are used or other means are used to write to the database.
> 2003-08-09 14:54:50,368 ERROR [org.apache.torque.util.BasePeer]
org.apache.torque.TorqueException: Connection is broken: Connection
refused: connect
This is probably the real problem. Torque is unable to connect to your
database. Make sure you've configured your Ohioedge CRM application
correctly, which may involve configuring Torque. If you need help with
Torque, see the Torque site which is now at http://db.apache.org/torque/
Otherwise, you may need to contact Ohioedge.
> 2003-08-09 14:54:50,378 INFO [STDOUT] 1308311 [PoolThread-9] ERROR
org.apache.torque.util.BasePeer - org.apache.torque.TorqueException:
Connection is broken: Connection refused: connect
> 2003-08-09 14:54:50,388 ERROR [org.apache.torque.util.BasePeer] A
> FATAL
ERROR has occurred which should not have happened under any
circumstance. Please notify the Turbine developers
<tu...@jakarta.apache.org> and give as many details as possible
(including the error stack trace).
> java.lang.Error: Error in BasePeer.initTableSchema(TURBINE_USER):
Connection is broken: Connection refused: connect
I'm fairly sure your problem is NOT with Turbine.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
AW: Can we delete RunDataFactory?
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi,
We are using RunDataFactory to test our actions, as explained in
http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaTurbine2Faq if this
is going to be deleted, is there going to be another way to test Turbine
Actions?
Kind regards
Jürgen Hoffmann
-----Ursprüngliche Nachricht-----
Von: Eric Pugh [mailto:epugh@upstate.com]
Gesendet: Mittwoch, 13. August 2003 00:45
An: 'Turbine Developers List'
Betreff: Can we delete RunDataFactory?
Hi all,
I noticed that RunDataFactory is really old. Notice this comment: //
NOTE: getRunData( HttpServletRequest req,
// HttpServletResponse res ) has been deprecated 3-3-2000.
// Wait a couple months (before Turbine 1.0) and remove this
// method.
I don't mind doing the work, but I think we should remove it as 1.0 has
been out a bit...
:-)
Eric
-----Original Message-----
From: Eric Emminger [mailto:eric@ericemminger.com]
Sent: Monday, August 11, 2003 5:39 PM
To: Turbine Developers List
Subject: Re: Reg: Error Occurred in Ohioedge CRM.
Velmurugan (Java) wrote:
> Hi All,
>
> When we run the application called "Ohioedge CRM" and got the
> following
error. Kindly help us how to trace out the solutions.I have followed all
the instrunctions which are given in installation document.
>
> Software's used.
> =============
>
> 1. JDK1.4.1
> 2. JBoss-3.2.1
>
> Platform
> =======
>
> Win-2K Professional.
>
>
> ERROR
>
========================================================================
====
==================
>
> 2003-08-09 14:54:46,363 INFO [STDOUT] 1304306 [Thread-44] DEBUG
org.apache.torque.oid.IDBroker - IDBroker thread was started.
> 2003-08-09 14:54:48,365 WARN [org.apache.torque.oid.IDBroker]
> IDBroker is
being used with db 'default', which does not support transactions.
IDBroker attempts to use transactions to limit the possibility of
duplicate key generation. Without transactions, duplicate key
generation is possible if multiple JVMs are used or other means are used
to write to the database.
> 2003-08-09 14:54:48,375 INFO [STDOUT] 1306308 [PoolThread-9] WARN
org.apache.torque.oid.IDBroker - IDBroker is being used with db
'default', which does not support transactions. IDBroker attempts to use
transactions to limit the possibility of duplicate key generation.
Without transactions, duplicate key generation is possible if multiple
JVMs are used or other means are used to write to the database.
> 2003-08-09 14:54:50,368 ERROR [org.apache.torque.util.BasePeer]
org.apache.torque.TorqueException: Connection is broken: Connection
refused: connect
This is probably the real problem. Torque is unable to connect to your
database. Make sure you've configured your Ohioedge CRM application
correctly, which may involve configuring Torque. If you need help with
Torque, see the Torque site which is now at http://db.apache.org/torque/
Otherwise, you may need to contact Ohioedge.
> 2003-08-09 14:54:50,378 INFO [STDOUT] 1308311 [PoolThread-9] ERROR
org.apache.torque.util.BasePeer - org.apache.torque.TorqueException:
Connection is broken: Connection refused: connect
> 2003-08-09 14:54:50,388 ERROR [org.apache.torque.util.BasePeer] A
> FATAL
ERROR has occurred which should not have happened under any
circumstance. Please notify the Turbine developers
<tu...@jakarta.apache.org> and give as many details as possible
(including the error stack trace).
> java.lang.Error: Error in BasePeer.initTableSchema(TURBINE_USER):
Connection is broken: Connection refused: connect
I'm fairly sure your problem is NOT with Turbine.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org