You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Jason van Zyl <jv...@apache.org> on 2001/09/03 06:57:27 UTC
Update
Hi,
I just wanted to throw out some notes and ideas that I thought about while
puttering around this weekend. In no particular order they are:
- try to use the pool service for RunData objects instead of a specific
RunDataService. I think the pool service is smart enough to take care of
this. ilkka, you might have some thoughts on this.
- using the pool service to retrieve instances of all classes used in
turbine. so there would basically be no more Foo f = new Foo(); anywhere and
the pool service would be used. we would have defined in a the configuration
the types of lists, map, etc ... we would use and we would pool everything
and make switching the type of class used very easy. move toward more
configuration and less hardcoding. I'm not really sure if there are cases
where it is more expensive to retrieve a pooled instance than create a new
one. I will look into it.
- I'd like it if people took a browse at RunData and DynamicURI. clean up
the interfaces as much as possible, I think there's some dupe methods in
there like data.getUser() and data.getUserFromSession().
- this I'd like to try and turn the mixture of classes and interfaces in the
top level package to interfaces with default implementations produced by a
factory. I was thinking that the processing of defaults could be like that
in velocity: lay down defaults from a properties file stored inside the JAR
and than lay app configuration info over top of that so there are guaranteed
valid values. once this is done than the mechanism will be in place for
dealing with the new pipeline, valve and renderer interfaces and default
implementations.
- someone whose interested in jsp should take a look at reviving the jsp
service. I will get to it eventually, but admittedly it's not on the top of
my list.
- I'm going to try and make a final pass over the module code and clean it
up to reduce it as much as possible.
- as mentioned above, the Renderer will probably become an interface along
with the Resolver. you might have a Resolver that finds templates in a
localized manner, or follow whatever criteria you wish.
- the TDK is working with all the changes made in the last couple of days
and I'm currently trying to make the same distribution work for 2.x and 3.x
applications so that migration can take place within the TDK. I work on
Tambora which is a 2.x application so I have a strong interest in making
this work easily.
That's it. I'm hoping this will get rolling again in the next week.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Update -- IRC (OT)
Posted by Jason van Zyl <jv...@apache.org>.
On 9/3/01 1:55 PM, "Dan Bachelder" <ch...@chowda.net> wrote:
> Just out of curiosity... where is the "official" IRC channel for turbine?
>
share.whichever.com:6667 #turbine
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Update -- IRC (OT)
Posted by Dan Bachelder <ch...@chowda.net>.
Just out of curiosity... where is the "official" IRC channel for turbine?
----- Original Message -----
From: "Jason van Zyl" <jv...@apache.org>
To: <tu...@jakarta.apache.org>
Sent: Monday, September 03, 2001 1:53 PM
Subject: Re: Update
> On 9/3/01 1:31 PM, "Ilkka Priha" <ip...@surfeu.fi> wrote:
>
> > Well, when directly asked, my opinion is that applications should not
> > contain so complicated classes that they can't initialize themselves.
Maybe
> > the problem is in the design of RunData, which requires a separate
service
> > for its initialization. PoolService is only for pooling and it should
not
> > know anything more about the objects it pools than the recycle and
dispose
> > methods.
> >
>
> I agree totally. Kasper and I were talking about this in IRC this morning.
> Kasper is going to try and simplify RunData.
>
> I definitely think the requirement of a separate service to manage this
> class is evidence of complexity. You are definitely right in that fact
that
> we should try to simplify the class instead of trying to get the pool
> service to deal with the complexity.
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 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: Update
Posted by Jason van Zyl <jv...@apache.org>.
On 9/3/01 1:31 PM, "Ilkka Priha" <ip...@surfeu.fi> wrote:
> Well, when directly asked, my opinion is that applications should not
> contain so complicated classes that they can't initialize themselves. Maybe
> the problem is in the design of RunData, which requires a separate service
> for its initialization. PoolService is only for pooling and it should not
> know anything more about the objects it pools than the recycle and dispose
> methods.
>
I agree totally. Kasper and I were talking about this in IRC this morning.
Kasper is going to try and simplify RunData.
I definitely think the requirement of a separate service to manage this
class is evidence of complexity. You are definitely right in that fact that
we should try to simplify the class instead of trying to get the pool
service to deal with the complexity.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Update
Posted by Ilkka Priha <ip...@surfeu.fi>.
Well, when directly asked, my opinion is that applications should not
contain so complicated classes that they can't initialize themselves. Maybe
the problem is in the design of RunData, which requires a separate service
for its initialization. PoolService is only for pooling and it should not
know anything more about the objects it pools than the recycle and dispose
methods.
-- Ilkka
----- Original Message -----
From: "Jason van Zyl" <jv...@apache.org>
To: <tu...@jakarta.apache.org>
Sent: Monday, September 03, 2001 19:48
Subject: Re: Update
> On 9/3/01 12:25 PM, "Ilkka Priha" <ip...@surfeu.fi> wrote:
>
> > RunDataService is on higher level than plain PoolService. It uses
internally
> > PoolService to get RunData, ParameterParser and CookieParser instances.
The
> > implementations to use for all of these can be configured in the service
> > properties. It also initializes RunData instances in a more complicated
way
> > than the RunData implementation itself could do (maybe it can be
extended to
> > initialize itself). PoolService is more general and can't be configured
to
> > perform such class specific tasks.
>
> Would it be much work to make the pool service handle these more
complicated
> tasks so that it could be used for object creation and pooling for classes
> like RunData? I'm sure we might come across the need to do this for more
> complicated situations and to have to create a service for each of the
> special situations might become cumbersome.
>
> > Pooling of small objects, objects with complicated constructors and
objects
> > that do have longer lifecycle than one request, is not useful. The
assembly
> > line memory management of Java is extremely efficient itself to handle
small
> > objects. Synchronization, reflection when calling constructors and
memory
> > management of the pools themselves decrease performance of pooling
compared
> > to instantiation.
> >
> > Also, it's often difficult to specify the exact point where it is safe
put
> > an object back to the pool. Handling this adds usually undesired
> > dependencies between objects. Implementations of Listener interfaces of
> > context tools, request and session attributes can be used to make
objects to
> > put themselves back to the pool when unbound from a container, which
helps
> > this job. But, again, Java's GC is an efficient tool to do all this for
you
> > automatically.
>
> Thanks for the tips, informative as always :-)
>
> > -- Ilkka
> >
> >
> > ----- Original Message -----
> > From: "Jason van Zyl" <jv...@apache.org>
> > To: <tu...@jakarta.apache.org>
> > Sent: Monday, September 03, 2001 07:57
> > Subject: Update
> >
> >
> >> Hi,
> >>
> >> I just wanted to throw out some notes and ideas that I thought about
while
> >> puttering around this weekend. In no particular order they are:
> >>
> >> - try to use the pool service for RunData objects instead of a specific
> >> RunDataService. I think the pool service is smart enough to take care
of
> >> this. ilkka, you might have some thoughts on this.
> >>
> >> - using the pool service to retrieve instances of all classes used in
> >> turbine. so there would basically be no more Foo f = new Foo();
anywhere
> > and
> >> the pool service would be used. we would have defined in a the
> > configuration
> >> the types of lists, map, etc ... we would use and we would pool
everything
> >> and make switching the type of class used very easy. move toward more
> >> configuration and less hardcoding. I'm not really sure if there are
cases
> >> where it is more expensive to retrieve a pooled instance than create a
new
> >> one. I will look into it.
> >>
> >> - I'd like it if people took a browse at RunData and DynamicURI. clean
up
> >> the interfaces as much as possible, I think there's some dupe methods
in
> >> there like data.getUser() and data.getUserFromSession().
> >>
> >> - this I'd like to try and turn the mixture of classes and interfaces
in
> > the
> >> top level package to interfaces with default implementations produced
by a
> >> factory. I was thinking that the processing of defaults could be like
that
> >> in velocity: lay down defaults from a properties file stored inside the
> > JAR
> >> and than lay app configuration info over top of that so there are
> > guaranteed
> >> valid values. once this is done than the mechanism will be in place for
> >> dealing with the new pipeline, valve and renderer interfaces and
default
> >> implementations.
> >>
> >> - someone whose interested in jsp should take a look at reviving the
jsp
> >> service. I will get to it eventually, but admittedly it's not on the
top
> > of
> >> my list.
> >>
> >> - I'm going to try and make a final pass over the module code and clean
it
> >> up to reduce it as much as possible.
> >>
> >> - as mentioned above, the Renderer will probably become an interface
along
> >> with the Resolver. you might have a Resolver that finds templates in a
> >> localized manner, or follow whatever criteria you wish.
> >>
> >> - the TDK is working with all the changes made in the last couple of
days
> >> and I'm currently trying to make the same distribution work for 2.x and
> > 3.x
> >> applications so that migration can take place within the TDK. I work on
> >> Tambora which is a 2.x application so I have a strong interest in
making
> >> this work easily.
> >>
> >> That's it. I'm hoping this will get rolling again in the next week.
> >>
> >> --
> >>
> >> jvz.
> >>
> >> Jason van Zyl
> >>
> >> http://tambora.zenplex.org
> >> http://jakarta.apache.org/turbine
> >> http://jakarta.apache.org/velocity
> >> http://jakarta.apache.org/alexandria
> >> http://jakarta.apache.org/commons
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: 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
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 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: Update
Posted by Jason van Zyl <jv...@apache.org>.
On 9/3/01 12:25 PM, "Ilkka Priha" <ip...@surfeu.fi> wrote:
> RunDataService is on higher level than plain PoolService. It uses internally
> PoolService to get RunData, ParameterParser and CookieParser instances. The
> implementations to use for all of these can be configured in the service
> properties. It also initializes RunData instances in a more complicated way
> than the RunData implementation itself could do (maybe it can be extended to
> initialize itself). PoolService is more general and can't be configured to
> perform such class specific tasks.
Would it be much work to make the pool service handle these more complicated
tasks so that it could be used for object creation and pooling for classes
like RunData? I'm sure we might come across the need to do this for more
complicated situations and to have to create a service for each of the
special situations might become cumbersome.
> Pooling of small objects, objects with complicated constructors and objects
> that do have longer lifecycle than one request, is not useful. The assembly
> line memory management of Java is extremely efficient itself to handle small
> objects. Synchronization, reflection when calling constructors and memory
> management of the pools themselves decrease performance of pooling compared
> to instantiation.
>
> Also, it's often difficult to specify the exact point where it is safe put
> an object back to the pool. Handling this adds usually undesired
> dependencies between objects. Implementations of Listener interfaces of
> context tools, request and session attributes can be used to make objects to
> put themselves back to the pool when unbound from a container, which helps
> this job. But, again, Java's GC is an efficient tool to do all this for you
> automatically.
Thanks for the tips, informative as always :-)
> -- Ilkka
>
>
> ----- Original Message -----
> From: "Jason van Zyl" <jv...@apache.org>
> To: <tu...@jakarta.apache.org>
> Sent: Monday, September 03, 2001 07:57
> Subject: Update
>
>
>> Hi,
>>
>> I just wanted to throw out some notes and ideas that I thought about while
>> puttering around this weekend. In no particular order they are:
>>
>> - try to use the pool service for RunData objects instead of a specific
>> RunDataService. I think the pool service is smart enough to take care of
>> this. ilkka, you might have some thoughts on this.
>>
>> - using the pool service to retrieve instances of all classes used in
>> turbine. so there would basically be no more Foo f = new Foo(); anywhere
> and
>> the pool service would be used. we would have defined in a the
> configuration
>> the types of lists, map, etc ... we would use and we would pool everything
>> and make switching the type of class used very easy. move toward more
>> configuration and less hardcoding. I'm not really sure if there are cases
>> where it is more expensive to retrieve a pooled instance than create a new
>> one. I will look into it.
>>
>> - I'd like it if people took a browse at RunData and DynamicURI. clean up
>> the interfaces as much as possible, I think there's some dupe methods in
>> there like data.getUser() and data.getUserFromSession().
>>
>> - this I'd like to try and turn the mixture of classes and interfaces in
> the
>> top level package to interfaces with default implementations produced by a
>> factory. I was thinking that the processing of defaults could be like that
>> in velocity: lay down defaults from a properties file stored inside the
> JAR
>> and than lay app configuration info over top of that so there are
> guaranteed
>> valid values. once this is done than the mechanism will be in place for
>> dealing with the new pipeline, valve and renderer interfaces and default
>> implementations.
>>
>> - someone whose interested in jsp should take a look at reviving the jsp
>> service. I will get to it eventually, but admittedly it's not on the top
> of
>> my list.
>>
>> - I'm going to try and make a final pass over the module code and clean it
>> up to reduce it as much as possible.
>>
>> - as mentioned above, the Renderer will probably become an interface along
>> with the Resolver. you might have a Resolver that finds templates in a
>> localized manner, or follow whatever criteria you wish.
>>
>> - the TDK is working with all the changes made in the last couple of days
>> and I'm currently trying to make the same distribution work for 2.x and
> 3.x
>> applications so that migration can take place within the TDK. I work on
>> Tambora which is a 2.x application so I have a strong interest in making
>> this work easily.
>>
>> That's it. I'm hoping this will get rolling again in the next week.
>>
>> --
>>
>> jvz.
>>
>> Jason van Zyl
>>
>> http://tambora.zenplex.org
>> http://jakarta.apache.org/turbine
>> http://jakarta.apache.org/velocity
>> http://jakarta.apache.org/alexandria
>> http://jakarta.apache.org/commons
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 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
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Update
Posted by Ilkka Priha <ip...@surfeu.fi>.
RunDataService is on higher level than plain PoolService. It uses internally
PoolService to get RunData, ParameterParser and CookieParser instances. The
implementations to use for all of these can be configured in the service
properties. It also initializes RunData instances in a more complicated way
than the RunData implementation itself could do (maybe it can be extended to
initialize itself). PoolService is more general and can't be configured to
perform such class specific tasks.
Pooling of small objects, objects with complicated constructors and objects
that do have longer lifecycle than one request, is not useful. The assembly
line memory management of Java is extremely efficient itself to handle small
objects. Synchronization, reflection when calling constructors and memory
management of the pools themselves decrease performance of pooling compared
to instantiation.
Also, it's often difficult to specify the exact point where it is safe put
an object back to the pool. Handling this adds usually undesired
dependencies between objects. Implementations of Listener interfaces of
context tools, request and session attributes can be used to make objects to
put themselves back to the pool when unbound from a container, which helps
this job. But, again, Java's GC is an efficient tool to do all this for you
automatically.
-- Ilkka
----- Original Message -----
From: "Jason van Zyl" <jv...@apache.org>
To: <tu...@jakarta.apache.org>
Sent: Monday, September 03, 2001 07:57
Subject: Update
> Hi,
>
> I just wanted to throw out some notes and ideas that I thought about while
> puttering around this weekend. In no particular order they are:
>
> - try to use the pool service for RunData objects instead of a specific
> RunDataService. I think the pool service is smart enough to take care of
> this. ilkka, you might have some thoughts on this.
>
> - using the pool service to retrieve instances of all classes used in
> turbine. so there would basically be no more Foo f = new Foo(); anywhere
and
> the pool service would be used. we would have defined in a the
configuration
> the types of lists, map, etc ... we would use and we would pool everything
> and make switching the type of class used very easy. move toward more
> configuration and less hardcoding. I'm not really sure if there are cases
> where it is more expensive to retrieve a pooled instance than create a new
> one. I will look into it.
>
> - I'd like it if people took a browse at RunData and DynamicURI. clean up
> the interfaces as much as possible, I think there's some dupe methods in
> there like data.getUser() and data.getUserFromSession().
>
> - this I'd like to try and turn the mixture of classes and interfaces in
the
> top level package to interfaces with default implementations produced by a
> factory. I was thinking that the processing of defaults could be like that
> in velocity: lay down defaults from a properties file stored inside the
JAR
> and than lay app configuration info over top of that so there are
guaranteed
> valid values. once this is done than the mechanism will be in place for
> dealing with the new pipeline, valve and renderer interfaces and default
> implementations.
>
> - someone whose interested in jsp should take a look at reviving the jsp
> service. I will get to it eventually, but admittedly it's not on the top
of
> my list.
>
> - I'm going to try and make a final pass over the module code and clean it
> up to reduce it as much as possible.
>
> - as mentioned above, the Renderer will probably become an interface along
> with the Resolver. you might have a Resolver that finds templates in a
> localized manner, or follow whatever criteria you wish.
>
> - the TDK is working with all the changes made in the last couple of days
> and I'm currently trying to make the same distribution work for 2.x and
3.x
> applications so that migration can take place within the TDK. I work on
> Tambora which is a 2.x application so I have a strong interest in making
> this work easily.
>
> That's it. I'm hoping this will get rolling again in the next week.
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 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: Update
Posted by Jason van Zyl <jv...@apache.org>.
On 9/3/01 1:09 AM, "Jon Stevens" <jo...@latchkey.com> wrote:
> on 9/2/01 9:57 PM, "Jason van Zyl" <jv...@apache.org> wrote:
>
>> I'm not really sure if there are cases
>> where it is more expensive to retrieve a pooled instance than create a new
>> one. I will look into it.
>
> It depends strongly on the JDK used. I have heard that in some of the newer
> JDK's (ie: 1.3 and 1.4), the GC can more than handle having tons of objects
> in memory.
>
> I think that when you want to use a pooled object is when that object does
> expensive init() stuff or is caching a lot of information internally.
>
> For example, in Scarab, we are caching a lot of the Torque BO's because
> those BO's might contain references to other BO's (for example, parent/child
> relationships within BO's). Therefore, the speed increase is worthwhile
> because it means fewer connections to the database which is clearly an
> expensive operation.
>
> My feeling is that if an object isn't doing anything expensive, then there
> isn't much need to pool instances of it.
There is also the additional benefit of easy configurability and
maintenance. If the using the pool in some cases is a performance killer
than that's one thing, but to be able to look at a glance and see all the
classes being used in Turbine would be a maintenance boon.
> -jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Update
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/2/01 9:57 PM, "Jason van Zyl" <jv...@apache.org> wrote:
> I'm not really sure if there are cases
> where it is more expensive to retrieve a pooled instance than create a new
> one. I will look into it.
It depends strongly on the JDK used. I have heard that in some of the newer
JDK's (ie: 1.3 and 1.4), the GC can more than handle having tons of objects
in memory.
I think that when you want to use a pooled object is when that object does
expensive init() stuff or is caching a lot of information internally.
For example, in Scarab, we are caching a lot of the Torque BO's because
those BO's might contain references to other BO's (for example, parent/child
relationships within BO's). Therefore, the speed increase is worthwhile
because it means fewer connections to the database which is clearly an
expensive operation.
My feeling is that if an object isn't doing anything expensive, then there
isn't much need to pool instances of it.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org