You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2003/01/06 13:32:00 UTC
RFC: Going to Servlet API 2.3+? [Was: Re: New SessionService....]
"Quinton McCombs" <qm...@nequalsone.com> writes:
>BTW - This added a dependency on servletapi-2.3. It is already in the
>ibiblio repository though....
I'm all +1 on going to Servlet API 2.3. But this is something for
Turbine 2.3. Not for 2.2.1.
After all, Servlet API 2.3 is here for ages and 2.4 is in proposed
final draft. And there is _lots_ of code we can remove, once we kick
pre-2.3 Servlet API.
Regards
Henning
>> -----Original Message-----
>> From: Quinton McCombs [mailto:qmccombs@nequalsone.com]
>> Sent: Sunday, January 05, 2003 1:05 PM
>> To: 'Turbine Developers List'
>> Subject: RE: New SessionService....
>>
>>
>> I have already solved the problem. I have the service
>> written, I will get it checked in today. I just need to
>> refactor it into the org.apache.turbine package structure....
>>
>> > -----Original Message-----
>> > From: Dave Everson [mailto:djeverson@mygolftrac.com]
>> > Sent: Sunday, January 05, 2003 12:28 PM
>> > To: Turbine Developers List
>> > Subject: Re: New SessionService....
>> >
>> >
>> > Hi Quinton,
>> >
>> > We just started talking about adding this functionality to
>> > our website so that the admins can check to see if anyone is
>> > logged in before doing maintenance or restarts. Do you have
>> > any code or advise that you could share so that we don't have
>> > to reinvent the same wheel if you have already solved this
>> > requirement.
>> >
>> > Thanks,
>> > Dave
>> >
>> > ----- Original Message -----
>> > From: "Quinton McCombs" <qm...@nequalsone.com>
>> > To: "Turbine Developers List" <tu...@jakarta.apache.org>
>> > Sent: Friday, January 03, 2003 10:43 AM
>> > Subject: New SessionService....
>> >
>> >
>> > I just posted a proposal for a new service to the Wiki...
>> >
>> http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaTurbine2/S
>essionServ
>ice
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RFC: Going to Servlet API 2.3+? [Was: Re: New SessionService....]
Posted by Martin Poeschl <mp...@marmot.at>.
Henning P. Schmiedehausen wrote:
>"Quinton McCombs" <qm...@nequalsone.com> writes:
>
>
>
>>BTW - This added a dependency on servletapi-2.3. It is already in the
>>ibiblio repository though....
>>
>>
>
>I'm all +1 on going to Servlet API 2.3. But this is something for
>Turbine 2.3. Not for 2.2.1.
>
+1
martin
>
>After all, Servlet API 2.3 is here for ages and 2.4 is in proposed
>final draft. And there is _lots_ of code we can remove, once we kick
>pre-2.3 Servlet API.
>
> Regards
> Henning
>
>
>
>
>
>
>>>-----Original Message-----
>>>From: Quinton McCombs [mailto:qmccombs@nequalsone.com]
>>>Sent: Sunday, January 05, 2003 1:05 PM
>>>To: 'Turbine Developers List'
>>>Subject: RE: New SessionService....
>>>
>>>
>>>I have already solved the problem. I have the service
>>>written, I will get it checked in today. I just need to
>>>refactor it into the org.apache.turbine package structure....
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Dave Everson [mailto:djeverson@mygolftrac.com]
>>>>Sent: Sunday, January 05, 2003 12:28 PM
>>>>To: Turbine Developers List
>>>>Subject: Re: New SessionService....
>>>>
>>>>
>>>>Hi Quinton,
>>>>
>>>>We just started talking about adding this functionality to
>>>>our website so that the admins can check to see if anyone is
>>>>logged in before doing maintenance or restarts. Do you have
>>>>any code or advise that you could share so that we don't have
>>>>to reinvent the same wheel if you have already solved this
>>>>requirement.
>>>>
>>>>Thanks,
>>>>Dave
>>>>
>>>>----- Original Message -----
>>>>From: "Quinton McCombs" <qm...@nequalsone.com>
>>>>To: "Turbine Developers List" <tu...@jakarta.apache.org>
>>>>Sent: Friday, January 03, 2003 10:43 AM
>>>>Subject: New SessionService....
>>>>
>>>>
>>>>I just posted a proposal for a new service to the Wiki...
>>>>
>>>>
>>>>
>>>http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaTurbine2/S
>>>
>>>
>>essionServ
>>ice
>>
>>
>
>
>
>
>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>>
>
>
>
>
>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>>
>
>
>
>
>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RFC: Going to Servlet API 2.3+? [Was: Re: New SessionService....]
Posted by Colin Chalmers <co...@maxware.nl>.
Was this not the whole idea behind Fulcrum?
/c
----- Original Message -----
From: "Chris K Chew" <ch...@fenetics.com>
To: "Turbine Developers List" <tu...@jakarta.apache.org>
Sent: Tuesday, January 07, 2003 1:19 AM
Subject: RE: RFC: Going to Servlet API 2.3+? [Was: Re: New
SessionService....]
> It might be worthwhile to consider packaging services independently from
the
> turbine core...simply include the service jar in the classpath, and it
gets
> loaded at startup. Advantages of this modular system include:
>
> *reduced complexity of TR.props
>
> *delete unused jars and cease the ever-growing filesize of the
applications
> built upon turbine
>
> *more progressive steps can be made with services (such is in the case of
> SessionService, where the question of api version requirements creeps in)
> because many decisions will only be service-wide instead of framework-wide
>
> *Bug fixes are limited to a service, and consequently more easily
> assimilated into production systems. For example, something like a bug
fix
> in the intake service won't require a whole new version of turbine (which
> may use the latest version of Torque that uses primitives instead of
Objects
> for Primary Keys, and now I am scared to upgrade...etc.)
>
> *Isolate possibly conflicting dependencies
>
> Of course, the disadvantage is the added burden of maintaining the various
> jars and service versions. But personally, and most software projects
> eventually come to the same decision, I feel that this extra burden is
more
> than paid for by the flexibility gained in a modularized release system.
>
> Chris
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RFC: Going to Servlet API 2.3+? [Was: Re: New SessionService....]
Posted by Stephen Haberman <st...@beachead.com>.
On Sat, Jan 11, 2003 at 01:08:17PM +0100, Henning Schmiedehausen wrote:
> While I'm quite agnostic, I'd like to see at least the basic things like
> Cache and Factory being bundled with Turbine or in a "Turbine Service
> Pack" (pun intended. ;-) ) If everyone wanting to use Turbine must put
> 20+ jars you need everytime in your POM, this will start to get a)
> annoying and b) drive people away.
I think that's a great idea unless Maven comes up with a way to
solve it for us.
I would hope that eventually with all of the pom
inheritance/extension stuff they're doing (or were doing, I haven't
been lurking on their mailing list for awhile now), that instead of
just jar dependencies you could have project dependencies, e.g.
putting 'turbine-2.3' as a project, not jar, dependency in your
project.xml, it would automatically go out to ibiblio and pull down
all of the associated jars.
(Perhaps now it could be done by inheriting from a single turbine
project.xml, but it would be nice to be able to bulk include jars
from various projects, hence making a given project a dependency
instead of inheriting from it and avoiding multiple inheritance).
This would be more elegant and cut down even more on the amount of
jars Turbine Service Pack would save us from manually listing in
poms, but would require some nifty processing (like versioning
conflict resolution) on Maven's end.
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RFC: Going to Servlet API 2.3+? [Was: Re: New
SessionService....]
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
Huh,
that Mail got drowned in my "apache" folder between all these "wiki
notification" messages from community@ ... =:-)
While I'm quite agnostic, I'd like to see at least the basic things like
Cache and Factory being bundled with Turbine or in a "Turbine Service
Pack" (pun intended. ;-) ) If everyone wanting to use Turbine must put
20+ jars you need everytime in your POM, this will start to get a)
annoying and b) drive people away.
Regards
Henning
On Wed, 2003-01-08 at 20:38, Daniel Rall wrote:
> On Tue, 7 Jan 2003, Henning P. Schmiedehausen wrote:
>
> > Daniel Rall <dl...@collab.net> writes:
> >
> > >Hullo Fulcrum.
> >
> > :-)
> >
> > Actually, this would be Fulcrum without the classes in the
> > org.apache.fulcrum package (but in the sub-packages).
>
> A one point we kicked around the idea for Fulcrum of packaging services in
> individual JAR files. I was never a fan of this idea, but am liking how
> things are turning out, with generally useful service cores getting pushed
> into Jakarta Commons, and Fulcrum services being simple wrappers around
> these pieces of functionality.
>
> - Dan
>
>
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RFC: Going to Servlet API 2.3+? [Was: Re: New SessionService....]
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 7 Jan 2003, Henning P. Schmiedehausen wrote:
> Daniel Rall <dl...@collab.net> writes:
>
> >Hullo Fulcrum.
>
> :-)
>
> Actually, this would be Fulcrum without the classes in the
> org.apache.fulcrum package (but in the sub-packages).
A one point we kicked around the idea for Fulcrum of packaging services in
individual JAR files. I was never a fan of this idea, but am liking how
things are turning out, with generally useful service cores getting pushed
into Jakarta Commons, and Fulcrum services being simple wrappers around
these pieces of functionality.
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RFC: Going to Servlet API 2.3+? [Was: Re: New SessionService....]
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Daniel Rall <dl...@collab.net> writes:
>Hullo Fulcrum.
:-)
Actually, this would be Fulcrum without the classes in the
org.apache.fulcrum package (but in the sub-packages).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine Roadmap?!?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Martin Poeschl <mp...@marmot.at> writes:
>It would be good to have a roadmap for Turbine > 2.2
>Turbine 2.3
>- the Services should stay as they are
>- Turbine should be able to use avalon components
> - Torque should be loaded as an avalon component
The Component Service should be able to use Avalon Components. Not the
Turbine Service Broker itself. This would be much too heavy.
>Turbine 2.3+
>- The services should be avalon components
Yes.
> - fulcrum or plexus??
Neither nor? The Fulcrum Service Broker is (except the class names)
the same as the current CVS HEAD Service Broker from Turbine (IMHO I
copied all the relevant parts).
We'd have to take a much closer look at Plexus to see whether this is
what we need and Jason told us (if I remember correctly) that "Plexus
is not ready for prime time and he prefers to develop off-Jakarta". So
in the end it might be Jasons' call. I don't want to simply drag this
code out of his CVS if he doesn't feel it is ready to do so.
>We should decide what will become turbine 3.0!
Definitely. Or Turbine Next Generation (hey, it would be TNG! %-) )
>Will the current turbine-3 code ever be released?
Don't know.
>Will Plexus/Summit replace the existing Turbine code?
> yes? when will this happen?
Why should it? Lets' call it Plexus/Summit and the Turbine Code
"Turbine". We just had a message on community@apache.org about
"cross-pollination". I liked it.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Turbine Roadmap?!?
Posted by Martin Poeschl <mp...@marmot.at>.
It would be good to have a roadmap for Turbine > 2.2
Turbine 2.3
- the Services should stay as they are
- Turbine should be able to use avalon components
- Torque should be loaded as an avalon component
Turbine 2.3+
- The services should be avalon components
- fulcrum or plexus??
We should decide what will become turbine 3.0!
Will the current turbine-3 code ever be released?
Will Plexus/Summit replace the existing Turbine code?
yes? when will this happen?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: RFC: Going to Servlet API 2.3+? [Was: Re: New SessionService....]
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 6 Jan 2003, Chris K Chew wrote:
> It might be worthwhile to consider packaging services independently from the
> turbine core...simply include the service jar in the classpath, and it gets
> loaded at startup. Advantages of this modular system include:
>
> *reduced complexity of TR.props
>
> *delete unused jars and cease the ever-growing filesize of the applications
> built upon turbine
>
> *more progressive steps can be made with services (such is in the case of
> SessionService, where the question of api version requirements creeps in)
> because many decisions will only be service-wide instead of framework-wide
>
> *Bug fixes are limited to a service, and consequently more easily
> assimilated into production systems. For example, something like a bug fix
> in the intake service won't require a whole new version of turbine (which
> may use the latest version of Torque that uses primitives instead of Objects
> for Primary Keys, and now I am scared to upgrade...etc.)
>
> *Isolate possibly conflicting dependencies
>
> Of course, the disadvantage is the added burden of maintaining the various
> jars and service versions. But personally, and most software projects
> eventually come to the same decision, I feel that this extra burden is more
> than paid for by the flexibility gained in a modularized release system.
Hullo Fulcrum.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: RFC: Going to Servlet API 2.3+? [Was: Re: New SessionService....]
Posted by Chris K Chew <ch...@fenetics.com>.
It might be worthwhile to consider packaging services independently from the
turbine core...simply include the service jar in the classpath, and it gets
loaded at startup. Advantages of this modular system include:
*reduced complexity of TR.props
*delete unused jars and cease the ever-growing filesize of the applications
built upon turbine
*more progressive steps can be made with services (such is in the case of
SessionService, where the question of api version requirements creeps in)
because many decisions will only be service-wide instead of framework-wide
*Bug fixes are limited to a service, and consequently more easily
assimilated into production systems. For example, something like a bug fix
in the intake service won't require a whole new version of turbine (which
may use the latest version of Torque that uses primitives instead of Objects
for Primary Keys, and now I am scared to upgrade...etc.)
*Isolate possibly conflicting dependencies
Of course, the disadvantage is the added burden of maintaining the various
jars and service versions. But personally, and most software projects
eventually come to the same decision, I feel that this extra burden is more
than paid for by the flexibility gained in a modularized release system.
Chris
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RFC: Going to Servlet API 2.3+? [Was: Re: New SessionService....]
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 6 Jan 2003, Henning P. Schmiedehausen wrote:
> "Quinton McCombs" <qm...@nequalsone.com> writes:
>
> >BTW - This added a dependency on servletapi-2.3. It is already in the
> >ibiblio repository though....
>
> I'm all +1 on going to Servlet API 2.3. But this is something for
> Turbine 2.3. Not for 2.2.1.
>
> After all, Servlet API 2.3 is here for ages and 2.4 is in proposed
> final draft. And there is _lots_ of code we can remove, once we kick
> pre-2.3 Servlet API.
I agree that this change doesn't have any business in 2.2.1.
Not having looked closely at the code, I assume that the compile-time and
run-time dependencies are specific to the new service. That is, one could
compile with Servlet API 2.3, then run with Servlet API 2.2 so long as
SessionService wasn't used. Putting a 2.3 dependency into the core of
Turbine would bear quite a bit more discussion, but putting such a
dependency into a single service seems fine.
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>