You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2006/07/18 01:54:41 UTC
Remove GeronimoExecutor?
Can we remove the interface GeronimoExecutor from Geronimo or at the
very least have no services use it? For those of you whom are not
aware of this interface, it adds a getName and getObjectName
interface to an Executor. Here is the code:
public interface GeronimoExecutor extends Executor,
org.apache.geronimo.system.threads.ThreadPool {
/**
* Gets a human-readable name identifying this object.
*/
String getName();
/**
* Gets the unique name of this object. The object name must
comply with
* the ObjectName specification in the JMX specification.
*
* @return the unique name of this object within the server
*/
String getObjectName();
}
I searched the code base and there isn't a single use of the getName
and getObjectName methods. The problem is the Work manager needs one
of these in the constructor, but it only uses the execute method
declared on in the Executor and ThreadPool interfaces. This means
that if you want to use the work manager you must take both the
geronimo-core and geronimo-system jars to get the GeronimoExecutor
and ThreadPool interfaces respectively.
So can we please please please remove this interface and just use
Executor?
I'd like to do this in both 1.2 and 1.1.1.
-dain
Re: Re: Re: Remove GeronimoExecutor?
Posted by James Strachan <ja...@gmail.com>.
If we ever had a single reusable annotations library (for things like
@Mandatory, @OneWay etc) we could have an annotation @Description to
be used to annotate a property used for descriptive purposes in
logs/consoles/UIs
On 7/18/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> On 7/17/06, James Strachan <ja...@gmail.com> wrote:
> > > The problem is that if you forget that, or use one bit of code outside
> > > our control (e.g. Tomcat, Jetty, etc.) you instantly get really nasty
> > > entries on the screen that shows the statistics. At least now we can
> > > tell which ones aren't implemented and just bundle those into an
> > > "unknown" category. I'm open to alternatives, but I don't like the
> > > toString one so much.
> >
> > How about having some optional interface such as Nameable...
>
> This would be possible (though I don't care about an ObjectName, just
> a human-readable name). But it still requires code changes which will
> be hard to enforce on third-party components. It might be ideal to
> have some sort of registry where you can say "Runnables of type
> org.mortbay.jetty.http.** should be identified as 'Jetty Execute
> Thread'". I haven't thought up a way to make that convenient either,
> though -- it has to be open to additions at runtime as new plugins are
> registered, etc.
>
> Thanks,
> Aaron
>
> > public interface Nameable {
> > /**
> > * Gets a human-readable name identifying this object.
> > */
> > String getName();
> >
> > /**
> > * Gets the unique name of this object. The object name must
> > comply with
> > * the ObjectName specification in the JMX specification.
> > *
> > * @return the unique name of this object within the server
> > */
> > String getObjectName();}
> > }
> >
> > Then any console related code could do an instanceof to see if the
> > implementation has carefully created a nice visual representation.
> > (Folks could use AOP to inject implementations too). This interface
> > can then be used across many different kinds of objects for consoles.
> >
> > Then code like the work manager can stick to regular interfaces like
> > Executor, Runnable etc? No biggie, just a thought.
> >
> >
> > > In any case, you can definitely remove GeronimoExecutor.
> >
> > +1
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Re: Re: Remove GeronimoExecutor?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 7/17/06, James Strachan <ja...@gmail.com> wrote:
> > The problem is that if you forget that, or use one bit of code outside
> > our control (e.g. Tomcat, Jetty, etc.) you instantly get really nasty
> > entries on the screen that shows the statistics. At least now we can
> > tell which ones aren't implemented and just bundle those into an
> > "unknown" category. I'm open to alternatives, but I don't like the
> > toString one so much.
>
> How about having some optional interface such as Nameable...
This would be possible (though I don't care about an ObjectName, just
a human-readable name). But it still requires code changes which will
be hard to enforce on third-party components. It might be ideal to
have some sort of registry where you can say "Runnables of type
org.mortbay.jetty.http.** should be identified as 'Jetty Execute
Thread'". I haven't thought up a way to make that convenient either,
though -- it has to be open to additions at runtime as new plugins are
registered, etc.
Thanks,
Aaron
> public interface Nameable {
> /**
> * Gets a human-readable name identifying this object.
> */
> String getName();
>
> /**
> * Gets the unique name of this object. The object name must
> comply with
> * the ObjectName specification in the JMX specification.
> *
> * @return the unique name of this object within the server
> */
> String getObjectName();}
> }
>
> Then any console related code could do an instanceof to see if the
> implementation has carefully created a nice visual representation.
> (Folks could use AOP to inject implementations too). This interface
> can then be used across many different kinds of objects for consoles.
>
> Then code like the work manager can stick to regular interfaces like
> Executor, Runnable etc? No biggie, just a thought.
>
>
> > In any case, you can definitely remove GeronimoExecutor.
>
> +1
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: Re: Remove GeronimoExecutor?
Posted by James Strachan <ja...@gmail.com>.
On 7/18/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> On 7/17/06, Dain Sundstrom <da...@iq80.com> wrote:
> > How about we just implement toString() on our Runnables, and our
> > thread pool can track that way? I really want to uncouple this code.
>
> The problem is that if you forget that, or use one bit of code outside
> our control (e.g. Tomcat, Jetty, etc.) you instantly get really nasty
> entries on the screen that shows the statistics. At least now we can
> tell which ones aren't implemented and just bundle those into an
> "unknown" category. I'm open to alternatives, but I don't like the
> toString one so much.
How about having some optional interface such as Nameable...
public interface Nameable {
/**
* Gets a human-readable name identifying this object.
*/
String getName();
/**
* Gets the unique name of this object. The object name must
comply with
* the ObjectName specification in the JMX specification.
*
* @return the unique name of this object within the server
*/
String getObjectName();}
}
Then any console related code could do an instanceof to see if the
implementation has carefully created a nice visual representation.
(Folks could use AOP to inject implementations too). This interface
can then be used across many different kinds of objects for consoles.
Then code like the work manager can stick to regular interfaces like
Executor, Runnable etc? No biggie, just a thought.
> In any case, you can definitely remove GeronimoExecutor.
+1
--
James
-------
http://radio.weblogs.com/0112098/
Re: Re: Remove GeronimoExecutor?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 7/17/06, Dain Sundstrom <da...@iq80.com> wrote:
> How about we just implement toString() on our Runnables, and our
> thread pool can track that way? I really want to uncouple this code.
The problem is that if you forget that, or use one bit of code outside
our control (e.g. Tomcat, Jetty, etc.) you instantly get really nasty
entries on the screen that shows the statistics. At least now we can
tell which ones aren't implemented and just bundle those into an
"unknown" category. I'm open to alternatives, but I don't like the
toString one so much.
In any case, you can definitely remove GeronimoExecutor.
Thanks,
Aaron
> On Jul 17, 2006, at 4:58 PM, Aaron Mulder wrote:
>
> > There's a method somewhere (perhaps ThreadPool) that takes a name and
> > a runnable and is useful in that the console can then show what kind
> > of work is being done with the thread pool -- particularly useful for
> > things like the default thread pool which can be used all over the
> > place. I don't really fancy removing that. But I'm fine with
> > removing the interface below.
> >
> > Thanks,
> > Aaron
> >
> > On 7/17/06, Dain Sundstrom <da...@iq80.com> wrote:
> >> Can we remove the interface GeronimoExecutor from Geronimo or at the
> >> very least have no services use it? For those of you whom are not
> >> aware of this interface, it adds a getName and getObjectName
> >> interface to an Executor. Here is the code:
> >>
> >> public interface GeronimoExecutor extends Executor,
> >> org.apache.geronimo.system.threads.ThreadPool {
> >> /**
> >> * Gets a human-readable name identifying this object.
> >> */
> >> String getName();
> >>
> >> /**
> >> * Gets the unique name of this object. The object name must
> >> comply with
> >> * the ObjectName specification in the JMX specification.
> >> *
> >> * @return the unique name of this object within the server
> >> */
> >> String getObjectName();
> >> }
> >>
> >> I searched the code base and there isn't a single use of the getName
> >> and getObjectName methods. The problem is the Work manager needs one
> >> of these in the constructor, but it only uses the execute method
> >> declared on in the Executor and ThreadPool interfaces. This means
> >> that if you want to use the work manager you must take both the
> >> geronimo-core and geronimo-system jars to get the GeronimoExecutor
> >> and ThreadPool interfaces respectively.
> >>
> >> So can we please please please remove this interface and just use
> >> Executor?
> >>
> >> I'd like to do this in both 1.2 and 1.1.1.
> >>
> >> -dain
> >>
>
>
Re: Remove GeronimoExecutor?
Posted by Dain Sundstrom <da...@iq80.com>.
How about we just implement toString() on our Runnables, and our
thread pool can track that way? I really want to uncouple this code.
-dain
On Jul 17, 2006, at 4:58 PM, Aaron Mulder wrote:
> There's a method somewhere (perhaps ThreadPool) that takes a name and
> a runnable and is useful in that the console can then show what kind
> of work is being done with the thread pool -- particularly useful for
> things like the default thread pool which can be used all over the
> place. I don't really fancy removing that. But I'm fine with
> removing the interface below.
>
> Thanks,
> Aaron
>
> On 7/17/06, Dain Sundstrom <da...@iq80.com> wrote:
>> Can we remove the interface GeronimoExecutor from Geronimo or at the
>> very least have no services use it? For those of you whom are not
>> aware of this interface, it adds a getName and getObjectName
>> interface to an Executor. Here is the code:
>>
>> public interface GeronimoExecutor extends Executor,
>> org.apache.geronimo.system.threads.ThreadPool {
>> /**
>> * Gets a human-readable name identifying this object.
>> */
>> String getName();
>>
>> /**
>> * Gets the unique name of this object. The object name must
>> comply with
>> * the ObjectName specification in the JMX specification.
>> *
>> * @return the unique name of this object within the server
>> */
>> String getObjectName();
>> }
>>
>> I searched the code base and there isn't a single use of the getName
>> and getObjectName methods. The problem is the Work manager needs one
>> of these in the constructor, but it only uses the execute method
>> declared on in the Executor and ThreadPool interfaces. This means
>> that if you want to use the work manager you must take both the
>> geronimo-core and geronimo-system jars to get the GeronimoExecutor
>> and ThreadPool interfaces respectively.
>>
>> So can we please please please remove this interface and just use
>> Executor?
>>
>> I'd like to do this in both 1.2 and 1.1.1.
>>
>> -dain
>>
Re: Remove GeronimoExecutor?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
There's a method somewhere (perhaps ThreadPool) that takes a name and
a runnable and is useful in that the console can then show what kind
of work is being done with the thread pool -- particularly useful for
things like the default thread pool which can be used all over the
place. I don't really fancy removing that. But I'm fine with
removing the interface below.
Thanks,
Aaron
On 7/17/06, Dain Sundstrom <da...@iq80.com> wrote:
> Can we remove the interface GeronimoExecutor from Geronimo or at the
> very least have no services use it? For those of you whom are not
> aware of this interface, it adds a getName and getObjectName
> interface to an Executor. Here is the code:
>
> public interface GeronimoExecutor extends Executor,
> org.apache.geronimo.system.threads.ThreadPool {
> /**
> * Gets a human-readable name identifying this object.
> */
> String getName();
>
> /**
> * Gets the unique name of this object. The object name must
> comply with
> * the ObjectName specification in the JMX specification.
> *
> * @return the unique name of this object within the server
> */
> String getObjectName();
> }
>
> I searched the code base and there isn't a single use of the getName
> and getObjectName methods. The problem is the Work manager needs one
> of these in the constructor, but it only uses the execute method
> declared on in the Executor and ThreadPool interfaces. This means
> that if you want to use the work manager you must take both the
> geronimo-core and geronimo-system jars to get the GeronimoExecutor
> and ThreadPool interfaces respectively.
>
> So can we please please please remove this interface and just use
> Executor?
>
> I'd like to do this in both 1.2 and 1.1.1.
>
> -dain
>