Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

I have an application metrics feature working on my local copy and I was 
wondering if there would be any interest in including it in the project.

A metric is a measure of average execution time. Each metric is given a 
unique name.

I modified the control servlet and service dispatcher to use metrics. To 
add a metric to a request, just include an XML element:

<metric name="URL: webtools/main" />

to the request map and the average response time for the URL will be 
maintained. Likewise, to add a metric to a service, just include an XML 
element:

<metric name="Service: createMaintsFromTimeInterval" />

to the service definition and the average execution time for the service 
will be maintained.

Metrics are kept in memory. There is a service to retrieve all metrics. 
There is also a Web Tools page to view all metrics.

A heartbeat server could retrieve the metrics to check on server load or 
to provide histograms.

The metric element has an optional threshold attribute, so some action 
could be taken when the metric crosses a threshold. For example, in the 
following request map:

<request-map uri="ViewMetrics">
     <security https="true" auth="true"/>
     <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
     <response name="success" type="view" value="ViewMetrics"/>
     <response name="threshold-exceeded" type="view" 
value="ServerBusy"/><!-- displays a friendly 'server busy' page -->
</request-map>

the ServerBusy view would be rendered if the average response time 
exceeded 1000 mS. This can be useful for providing a lively web 
experience on a heavy-traffic web page.

The service dispatcher does not use the threshold. I could not think of 
a use case where service behavior should be modified based on average 
execution time.

The metrics code is very small - two java files. Also, the modifications 
to the webapp component and service component are very small.

What do you think?

-Adrian

Re: Discussion: Application Metrics Feature

[Jacques Le Roux <ja...@les7arts.com>]

+1, looks quite good to me!

Jacques

From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> Adrian,
>
> thank you for the clear description and proposal; I like it very much and I would be happy to see it in OFBiz.
>
> Regards,
>
> Jacopo
>
> On Jul 14, 2012, at 12:38 PM, Adrian Crum wrote:
>
>> I have an application metrics feature working on my local copy and I was wondering if there would be any interest in including it 
>> in the project.
>>
>> A metric is a measure of average execution time. Each metric is given a unique name.
>>
>> I modified the control servlet and service dispatcher to use metrics. To add a metric to a request, just include an XML element:
>>
>> <metric name="URL: webtools/main" />
>>
>> to the request map and the average response time for the URL will be maintained. Likewise, to add a metric to a service, just 
>> include an XML element:
>>
>> <metric name="Service: createMaintsFromTimeInterval" />
>>
>> to the service definition and the average execution time for the service will be maintained.
>>
>> Metrics are kept in memory. There is a service to retrieve all metrics. There is also a Web Tools page to view all metrics.
>>
>> A heartbeat server could retrieve the metrics to check on server load or to provide histograms.
>>
>> The metric element has an optional threshold attribute, so some action could be taken when the metric crosses a threshold. For 
>> example, in the following request map:
>>
>> <request-map uri="ViewMetrics">
>>    <security https="true" auth="true"/>
>>    <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>    <response name="success" type="view" value="ViewMetrics"/>
>>    <response name="threshold-exceeded" type="view" value="ServerBusy"/><!-- displays a friendly 'server busy' page -->
>> </request-map>
>>
>> the ServerBusy view would be rendered if the average response time exceeded 1000 mS. This can be useful for providing a lively 
>> web experience on a heavy-traffic web page.
>>
>> The service dispatcher does not use the threshold. I could not think of a use case where service behavior should be modified 
>> based on average execution time.
>>
>> The metrics code is very small - two java files. Also, the modifications to the webapp component and service component are very 
>> small.
>>
>> What do you think?
>>
>> -Adrian
>>
>
> 

Re: Discussion: Application Metrics Feature

[Olivier Heintz <ho...@nereide.biz>]

Le 16/07/2012 12:04, Adrian Crum a écrit :
> If anyone is placing themselves over anyone else, it is you. Scott and 
> I are trying to help you understand how this community works, but you 
> are not interested in being taught - you are only interested in 
> railroading through your opinions.
I completely agree with Adrian and Scott, their answers are clear and 
only re-explain goal of each mailing-list.
>
> -Adrian
>
> On 7/16/2012 10:59 AM, Pierre Smits wrote:
>> This isn't about what the mailing lists are for.
>>
>> Don't try to fill in what others care about or need. But it would
>> definitely help if you would be a community member first, in stead of
>> placing yourself above it.
>>
>>
>> 2012/7/16 Scott Gray <sc...@hotwaxmedia.com>
>>
>>> It all comes back to a general misunderstanding of the difference 
>>> between
>>> the user and dev lists.
>>>
>>> The user list is for people who are using OFBiz as a business user or
>>> developing customized applications.  When these types of people have a
>>> question, the user list is definitely appropriate.  They don't 
>>> necessarily
>>> care about the ongoing development of OFBiz itself, they need to 
>>> discuss
>>> how to use what has been released.
>>> The dev list is for people who are interested in the ongoing 
>>> development
>>> of OFBiz and wish to contribute code, documentation and ideas.  If 
>>> you care
>>> about the future of OFBiz then this is where you come and contribute.
>>>
>>> No one is attempting to exclude OFBiz users from any discussions, if 
>>> they
>>> want to be involved in the development of OFBiz then they subscribe 
>>> to the
>>> dev list just like everyone else.  I feel like a broken record 
>>> though, is
>>> there some way that we can more clearly articulate the distinction 
>>> to the
>>> community?
>>>
>>> Regards
>>> Scott
>>>
>>> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>>>
>>>> You mean excluding parts of the community from participating in the
>>>> decision-taking processes?
>>>>
>>>> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>>>>
>>>>> No, it smells like the current goal of moving things we don't want in
>>> the
>>>>> main project to external projects. This type of decision-making 
>>>>> has been
>>>>> going on for years.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>>>
>>>>>> I agree with Ruth. This sounds like a user requirement. And the
>>> community
>>>>>> should decide on this.
>>>>>>
>>>>>> Furthermore, the remark 'users might like a new feature, but that
>>> doesn't
>>>>>> mean the dev community wants it in the project' smells like 
>>>>>> measuring
>>> with
>>>>>> double standards; as if the meritocratic principle doesn't apply 
>>>>>> when
>>> the
>>>>>> committers don't want it in. Or as if changes always get in, when 
>>>>>> only
>>> the
>>>>>> committers want it.
>>>>>>
>>>>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**software.com<
>>> adrian.crum@sandglass-software.com>
>>>>>> Ruth,
>>>>>>> I understand your viewpoint. Personally, I prefer to present my 
>>>>>>> ideas
>>> to
>>>>>>> the dev list to see if it is something the dev community wants
>>> included
>>>>>>> in
>>>>>>> the project. Users might like a new feature, but that doesn't 
>>>>>>> mean the
>>>>>>> dev
>>>>>>> community wants it in the project. If there was no interest from 
>>>>>>> the
>>> dev
>>>>>>> community, then I would offer it as an add-on product and 
>>>>>>> announce it
>>> on
>>>>>>> the user list.
>>>>>>>
>>>>>>> I am also a user, and the design was based on the requirement to
>>> monitor
>>>>>>> and control server performance. I suppose I could go to the user 
>>>>>>> list
>>> for
>>>>>>> more ideas, but the code I'm planning to commit is pretty basic, 
>>>>>>> and
>>>>>>> users
>>>>>>> will be free to enhance it in whatever way they please.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>>>
>>>>>>> Hi Adrian:
>>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>>> "applications" and "stats about services and entities"...those are
>>> all
>>>>>>>> indicative of user requirements, not developer requirements.
>>>>>>>>
>>>>>>>> Users should be driving requirements gathering and analysis for 
>>>>>>>> OFBiz
>>>>>>>> and
>>>>>>>> not developers.
>>>>>>>> Just my 2 cents.
>>>>>>>> Regards,
>>>>>>>> Ruth
>>>>>>>>
>>>>>>>>
>>>>>
>>>
>
>
>

Re: Discussion: Application Metrics Feature

[Pierre Smits <pi...@gmail.com>]

And for expressing that you think of it as if I need to be taught something
as a little child.

2012/7/16 Pierre Smits <pi...@gmail.com>

> Thank you, Adrian, for your opinion.
>
>
> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>
>> If anyone is placing themselves over anyone else, it is you. Scott and I
>> are trying to help you understand how this community works, but you are not
>> interested in being taught - you are only interested in railroading through
>> your opinions.
>>
>> -Adrian
>>
>>
>> On 7/16/2012 10:59 AM, Pierre Smits wrote:
>>
>>> This isn't about what the mailing lists are for.
>>>
>>> Don't try to fill in what others care about or need. But it would
>>> definitely help if you would be a community member first, in stead of
>>> placing yourself above it.
>>>
>>>
>>> 2012/7/16 Scott Gray <sc...@hotwaxmedia.com>
>>>
>>>  It all comes back to a general misunderstanding of the difference
>>>> between
>>>> the user and dev lists.
>>>>
>>>> The user list is for people who are using OFBiz as a business user or
>>>> developing customized applications.  When these types of people have a
>>>> question, the user list is definitely appropriate.  They don't
>>>> necessarily
>>>> care about the ongoing development of OFBiz itself, they need to discuss
>>>> how to use what has been released.
>>>> The dev list is for people who are interested in the ongoing development
>>>> of OFBiz and wish to contribute code, documentation and ideas.  If you
>>>> care
>>>> about the future of OFBiz then this is where you come and contribute.
>>>>
>>>> No one is attempting to exclude OFBiz users from any discussions, if
>>>> they
>>>> want to be involved in the development of OFBiz then they subscribe to
>>>> the
>>>> dev list just like everyone else.  I feel like a broken record though,
>>>> is
>>>> there some way that we can more clearly articulate the distinction to
>>>> the
>>>> community?
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>>>>
>>>>  You mean excluding parts of the community from participating in the
>>>>> decision-taking processes?
>>>>>
>>>>> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>>>>> >
>>>>>
>>>>>  No, it smells like the current goal of moving things we don't want in
>>>>>>
>>>>> the
>>>>
>>>>> main project to external projects. This type of decision-making has
>>>>>> been
>>>>>> going on for years.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>>>>
>>>>>>  I agree with Ruth. This sounds like a user requirement. And the
>>>>>>>
>>>>>> community
>>>>
>>>>> should decide on this.
>>>>>>>
>>>>>>> Furthermore, the remark 'users might like a new feature, but that
>>>>>>>
>>>>>> doesn't
>>>>
>>>>> mean the dev community wants it in the project' smells like measuring
>>>>>>>
>>>>>> with
>>>>
>>>>> double standards; as if the meritocratic principle doesn't apply when
>>>>>>>
>>>>>> the
>>>>
>>>>> committers don't want it in. Or as if changes always get in, when only
>>>>>>>
>>>>>> the
>>>>
>>>>> committers want it.
>>>>>>>
>>>>>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**softw**are.com<http://software.com>
>>>>>>> <
>>>>>>>
>>>>>> adrian.crum@sandglass-**software.com<ad...@sandglass-software.com>
>>>> >
>>>>
>>>>> Ruth,
>>>>>>>
>>>>>>>> I understand your viewpoint. Personally, I prefer to present my
>>>>>>>> ideas
>>>>>>>>
>>>>>>> to
>>>>
>>>>>  the dev list to see if it is something the dev community wants
>>>>>>>>
>>>>>>> included
>>>>
>>>>>  in
>>>>>>>> the project. Users might like a new feature, but that doesn't mean
>>>>>>>> the
>>>>>>>> dev
>>>>>>>> community wants it in the project. If there was no interest from the
>>>>>>>>
>>>>>>> dev
>>>>
>>>>>  community, then I would offer it as an add-on product and announce it
>>>>>>>>
>>>>>>> on
>>>>
>>>>>  the user list.
>>>>>>>>
>>>>>>>> I am also a user, and the design was based on the requirement to
>>>>>>>>
>>>>>>> monitor
>>>>
>>>>>  and control server performance. I suppose I could go to the user list
>>>>>>>>
>>>>>>> for
>>>>
>>>>>  more ideas, but the code I'm planning to commit is pretty basic, and
>>>>>>>> users
>>>>>>>> will be free to enhance it in whatever way they please.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>>>>
>>>>>>>> Hi Adrian:
>>>>>>>>
>>>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>>>> "applications" and "stats about services and entities"...those are
>>>>>>>>>
>>>>>>>> all
>>>>
>>>>>  indicative of user requirements, not developer requirements.
>>>>>>>>>
>>>>>>>>> Users should be driving requirements gathering and analysis for
>>>>>>>>> OFBiz
>>>>>>>>> and
>>>>>>>>> not developers.
>>>>>>>>> Just my 2 cents.
>>>>>>>>> Regards,
>>>>>>>>> Ruth
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>
>>
>

Re: Discussion: Application Metrics Feature

[Pierre Smits <pi...@gmail.com>]

Thank you, Adrian, for your opinion.

2012/7/16 Adrian Crum <ad...@sandglass-software.com>

> If anyone is placing themselves over anyone else, it is you. Scott and I
> are trying to help you understand how this community works, but you are not
> interested in being taught - you are only interested in railroading through
> your opinions.
>
> -Adrian
>
>
> On 7/16/2012 10:59 AM, Pierre Smits wrote:
>
>> This isn't about what the mailing lists are for.
>>
>> Don't try to fill in what others care about or need. But it would
>> definitely help if you would be a community member first, in stead of
>> placing yourself above it.
>>
>>
>> 2012/7/16 Scott Gray <sc...@hotwaxmedia.com>
>>
>>  It all comes back to a general misunderstanding of the difference between
>>> the user and dev lists.
>>>
>>> The user list is for people who are using OFBiz as a business user or
>>> developing customized applications.  When these types of people have a
>>> question, the user list is definitely appropriate.  They don't
>>> necessarily
>>> care about the ongoing development of OFBiz itself, they need to discuss
>>> how to use what has been released.
>>> The dev list is for people who are interested in the ongoing development
>>> of OFBiz and wish to contribute code, documentation and ideas.  If you
>>> care
>>> about the future of OFBiz then this is where you come and contribute.
>>>
>>> No one is attempting to exclude OFBiz users from any discussions, if they
>>> want to be involved in the development of OFBiz then they subscribe to
>>> the
>>> dev list just like everyone else.  I feel like a broken record though, is
>>> there some way that we can more clearly articulate the distinction to the
>>> community?
>>>
>>> Regards
>>> Scott
>>>
>>> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>>>
>>>  You mean excluding parts of the community from participating in the
>>>> decision-taking processes?
>>>>
>>>> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>>>> >
>>>>
>>>>  No, it smells like the current goal of moving things we don't want in
>>>>>
>>>> the
>>>
>>>> main project to external projects. This type of decision-making has been
>>>>> going on for years.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>>>
>>>>>  I agree with Ruth. This sounds like a user requirement. And the
>>>>>>
>>>>> community
>>>
>>>> should decide on this.
>>>>>>
>>>>>> Furthermore, the remark 'users might like a new feature, but that
>>>>>>
>>>>> doesn't
>>>
>>>> mean the dev community wants it in the project' smells like measuring
>>>>>>
>>>>> with
>>>
>>>> double standards; as if the meritocratic principle doesn't apply when
>>>>>>
>>>>> the
>>>
>>>> committers don't want it in. Or as if changes always get in, when only
>>>>>>
>>>>> the
>>>
>>>> committers want it.
>>>>>>
>>>>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**softw**are.com<http://software.com>
>>>>>> <
>>>>>>
>>>>> adrian.crum@sandglass-**software.com<ad...@sandglass-software.com>
>>> >
>>>
>>>> Ruth,
>>>>>>
>>>>>>> I understand your viewpoint. Personally, I prefer to present my ideas
>>>>>>>
>>>>>> to
>>>
>>>> the dev list to see if it is something the dev community wants
>>>>>>>
>>>>>> included
>>>
>>>> in
>>>>>>> the project. Users might like a new feature, but that doesn't mean
>>>>>>> the
>>>>>>> dev
>>>>>>> community wants it in the project. If there was no interest from the
>>>>>>>
>>>>>> dev
>>>
>>>> community, then I would offer it as an add-on product and announce it
>>>>>>>
>>>>>> on
>>>
>>>> the user list.
>>>>>>>
>>>>>>> I am also a user, and the design was based on the requirement to
>>>>>>>
>>>>>> monitor
>>>
>>>> and control server performance. I suppose I could go to the user list
>>>>>>>
>>>>>> for
>>>
>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>>>>> users
>>>>>>> will be free to enhance it in whatever way they please.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>>>
>>>>>>> Hi Adrian:
>>>>>>>
>>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>>> "applications" and "stats about services and entities"...those are
>>>>>>>>
>>>>>>> all
>>>
>>>> indicative of user requirements, not developer requirements.
>>>>>>>>
>>>>>>>> Users should be driving requirements gathering and analysis for
>>>>>>>> OFBiz
>>>>>>>> and
>>>>>>>> not developers.
>>>>>>>> Just my 2 cents.
>>>>>>>> Regards,
>>>>>>>> Ruth
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>
>
>

Re: Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

If anyone is placing themselves over anyone else, it is you. Scott and I 
are trying to help you understand how this community works, but you are 
not interested in being taught - you are only interested in railroading 
through your opinions.

-Adrian

On 7/16/2012 10:59 AM, Pierre Smits wrote:
> This isn't about what the mailing lists are for.
>
> Don't try to fill in what others care about or need. But it would
> definitely help if you would be a community member first, in stead of
> placing yourself above it.
>
>
> 2012/7/16 Scott Gray <sc...@hotwaxmedia.com>
>
>> It all comes back to a general misunderstanding of the difference between
>> the user and dev lists.
>>
>> The user list is for people who are using OFBiz as a business user or
>> developing customized applications.  When these types of people have a
>> question, the user list is definitely appropriate.  They don't necessarily
>> care about the ongoing development of OFBiz itself, they need to discuss
>> how to use what has been released.
>> The dev list is for people who are interested in the ongoing development
>> of OFBiz and wish to contribute code, documentation and ideas.  If you care
>> about the future of OFBiz then this is where you come and contribute.
>>
>> No one is attempting to exclude OFBiz users from any discussions, if they
>> want to be involved in the development of OFBiz then they subscribe to the
>> dev list just like everyone else.  I feel like a broken record though, is
>> there some way that we can more clearly articulate the distinction to the
>> community?
>>
>> Regards
>> Scott
>>
>> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>>
>>> You mean excluding parts of the community from participating in the
>>> decision-taking processes?
>>>
>>> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>>>
>>>> No, it smells like the current goal of moving things we don't want in
>> the
>>>> main project to external projects. This type of decision-making has been
>>>> going on for years.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>>
>>>>> I agree with Ruth. This sounds like a user requirement. And the
>> community
>>>>> should decide on this.
>>>>>
>>>>> Furthermore, the remark 'users might like a new feature, but that
>> doesn't
>>>>> mean the dev community wants it in the project' smells like measuring
>> with
>>>>> double standards; as if the meritocratic principle doesn't apply when
>> the
>>>>> committers don't want it in. Or as if changes always get in, when only
>> the
>>>>> committers want it.
>>>>>
>>>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**software.com<
>> adrian.crum@sandglass-software.com>
>>>>> Ruth,
>>>>>> I understand your viewpoint. Personally, I prefer to present my ideas
>> to
>>>>>> the dev list to see if it is something the dev community wants
>> included
>>>>>> in
>>>>>> the project. Users might like a new feature, but that doesn't mean the
>>>>>> dev
>>>>>> community wants it in the project. If there was no interest from the
>> dev
>>>>>> community, then I would offer it as an add-on product and announce it
>> on
>>>>>> the user list.
>>>>>>
>>>>>> I am also a user, and the design was based on the requirement to
>> monitor
>>>>>> and control server performance. I suppose I could go to the user list
>> for
>>>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>>>> users
>>>>>> will be free to enhance it in whatever way they please.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>>
>>>>>> Hi Adrian:
>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>> "applications" and "stats about services and entities"...those are
>> all
>>>>>>> indicative of user requirements, not developer requirements.
>>>>>>>
>>>>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>>>>> and
>>>>>>> not developers.
>>>>>>> Just my 2 cents.
>>>>>>> Regards,
>>>>>>> Ruth
>>>>>>>
>>>>>>>
>>>>
>>

Re: Discussion: Application Metrics Feature

[Scott Gray <sc...@hotwaxmedia.com>]

No, that's exactly what this discussion is about, here let me remind you about what Ruth asked:
> Shouldn't this be discussed on the "user" list?

The mailing lists are what they are, I'm just describing the purposes that they are intended to fill.  I'm not placing myself above the community, I don't even know how to respond to that.

Regards
Scott

On 16/07/2012, at 9:59 PM, Pierre Smits wrote:

> This isn't about what the mailing lists are for.
> 
> Don't try to fill in what others care about or need. But it would
> definitely help if you would be a community member first, in stead of
> placing yourself above it.
> 
> 
> 2012/7/16 Scott Gray <sc...@hotwaxmedia.com>
> 
>> It all comes back to a general misunderstanding of the difference between
>> the user and dev lists.
>> 
>> The user list is for people who are using OFBiz as a business user or
>> developing customized applications.  When these types of people have a
>> question, the user list is definitely appropriate.  They don't necessarily
>> care about the ongoing development of OFBiz itself, they need to discuss
>> how to use what has been released.
>> The dev list is for people who are interested in the ongoing development
>> of OFBiz and wish to contribute code, documentation and ideas.  If you care
>> about the future of OFBiz then this is where you come and contribute.
>> 
>> No one is attempting to exclude OFBiz users from any discussions, if they
>> want to be involved in the development of OFBiz then they subscribe to the
>> dev list just like everyone else.  I feel like a broken record though, is
>> there some way that we can more clearly articulate the distinction to the
>> community?
>> 
>> Regards
>> Scott
>> 
>> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>> 
>>> You mean excluding parts of the community from participating in the
>>> decision-taking processes?
>>> 
>>> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>>> 
>>>> No, it smells like the current goal of moving things we don't want in
>> the
>>>> main project to external projects. This type of decision-making has been
>>>> going on for years.
>>>> 
>>>> -Adrian
>>>> 
>>>> 
>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>> 
>>>>> I agree with Ruth. This sounds like a user requirement. And the
>> community
>>>>> should decide on this.
>>>>> 
>>>>> Furthermore, the remark 'users might like a new feature, but that
>> doesn't
>>>>> mean the dev community wants it in the project' smells like measuring
>> with
>>>>> double standards; as if the meritocratic principle doesn't apply when
>> the
>>>>> committers don't want it in. Or as if changes always get in, when only
>> the
>>>>> committers want it.
>>>>> 
>>>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**software.com<
>> adrian.crum@sandglass-software.com>
>>>>>> 
>>>>> 
>>>>> Ruth,
>>>>>> 
>>>>>> I understand your viewpoint. Personally, I prefer to present my ideas
>> to
>>>>>> the dev list to see if it is something the dev community wants
>> included
>>>>>> in
>>>>>> the project. Users might like a new feature, but that doesn't mean the
>>>>>> dev
>>>>>> community wants it in the project. If there was no interest from the
>> dev
>>>>>> community, then I would offer it as an add-on product and announce it
>> on
>>>>>> the user list.
>>>>>> 
>>>>>> I am also a user, and the design was based on the requirement to
>> monitor
>>>>>> and control server performance. I suppose I could go to the user list
>> for
>>>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>>>> users
>>>>>> will be free to enhance it in whatever way they please.
>>>>>> 
>>>>>> -Adrian
>>>>>> 
>>>>>> 
>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>> 
>>>>>> Hi Adrian:
>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>> "applications" and "stats about services and entities"...those are
>> all
>>>>>>> indicative of user requirements, not developer requirements.
>>>>>>> 
>>>>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>>>>> and
>>>>>>> not developers.
>>>>>>> Just my 2 cents.
>>>>>>> Regards,
>>>>>>> Ruth
>>>>>>> 
>>>>>>> 
>>>> 
>>>> 
>> 
>> 

Re: Discussion: Application Metrics Feature

[Pierre Smits <pi...@gmail.com>]

This isn't about what the mailing lists are for.

Don't try to fill in what others care about or need. But it would
definitely help if you would be a community member first, in stead of
placing yourself above it.


2012/7/16 Scott Gray <sc...@hotwaxmedia.com>

> It all comes back to a general misunderstanding of the difference between
> the user and dev lists.
>
> The user list is for people who are using OFBiz as a business user or
> developing customized applications.  When these types of people have a
> question, the user list is definitely appropriate.  They don't necessarily
> care about the ongoing development of OFBiz itself, they need to discuss
> how to use what has been released.
> The dev list is for people who are interested in the ongoing development
> of OFBiz and wish to contribute code, documentation and ideas.  If you care
> about the future of OFBiz then this is where you come and contribute.
>
> No one is attempting to exclude OFBiz users from any discussions, if they
> want to be involved in the development of OFBiz then they subscribe to the
> dev list just like everyone else.  I feel like a broken record though, is
> there some way that we can more clearly articulate the distinction to the
> community?
>
> Regards
> Scott
>
> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>
> > You mean excluding parts of the community from participating in the
> > decision-taking processes?
> >
> > 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
> >
> >> No, it smells like the current goal of moving things we don't want in
> the
> >> main project to external projects. This type of decision-making has been
> >> going on for years.
> >>
> >> -Adrian
> >>
> >>
> >> On 7/16/2012 9:45 AM, Pierre Smits wrote:
> >>
> >>> I agree with Ruth. This sounds like a user requirement. And the
> community
> >>> should decide on this.
> >>>
> >>> Furthermore, the remark 'users might like a new feature, but that
> doesn't
> >>> mean the dev community wants it in the project' smells like measuring
> with
> >>> double standards; as if the meritocratic principle doesn't apply when
> the
> >>> committers don't want it in. Or as if changes always get in, when only
> the
> >>> committers want it.
> >>>
> >>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**software.com<
> adrian.crum@sandglass-software.com>
> >>>>
> >>>
> >>> Ruth,
> >>>>
> >>>> I understand your viewpoint. Personally, I prefer to present my ideas
> to
> >>>> the dev list to see if it is something the dev community wants
> included
> >>>> in
> >>>> the project. Users might like a new feature, but that doesn't mean the
> >>>> dev
> >>>> community wants it in the project. If there was no interest from the
> dev
> >>>> community, then I would offer it as an add-on product and announce it
> on
> >>>> the user list.
> >>>>
> >>>> I am also a user, and the design was based on the requirement to
> monitor
> >>>> and control server performance. I suppose I could go to the user list
> for
> >>>> more ideas, but the code I'm planning to commit is pretty basic, and
> >>>> users
> >>>> will be free to enhance it in whatever way they please.
> >>>>
> >>>> -Adrian
> >>>>
> >>>>
> >>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
> >>>>
> >>>> Hi Adrian:
> >>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
> >>>>> "applications" and "stats about services and entities"...those are
> all
> >>>>> indicative of user requirements, not developer requirements.
> >>>>>
> >>>>> Users should be driving requirements gathering and analysis for OFBiz
> >>>>> and
> >>>>> not developers.
> >>>>> Just my 2 cents.
> >>>>> Regards,
> >>>>> Ruth
> >>>>>
> >>>>>
> >>
> >>
>
>

Re: Discussion: Application Metrics Feature

[Scott Gray <sc...@hotwaxmedia.com>]

It all comes back to a general misunderstanding of the difference between the user and dev lists.

The user list is for people who are using OFBiz as a business user or developing customized applications.  When these types of people have a question, the user list is definitely appropriate.  They don't necessarily care about the ongoing development of OFBiz itself, they need to discuss how to use what has been released.
The dev list is for people who are interested in the ongoing development of OFBiz and wish to contribute code, documentation and ideas.  If you care about the future of OFBiz then this is where you come and contribute.

No one is attempting to exclude OFBiz users from any discussions, if they want to be involved in the development of OFBiz then they subscribe to the dev list just like everyone else.  I feel like a broken record though, is there some way that we can more clearly articulate the distinction to the community?

Regards
Scott

On 16/07/2012, at 9:11 PM, Pierre Smits wrote:

> You mean excluding parts of the community from participating in the
> decision-taking processes?
> 
> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
> 
>> No, it smells like the current goal of moving things we don't want in the
>> main project to external projects. This type of decision-making has been
>> going on for years.
>> 
>> -Adrian
>> 
>> 
>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>> 
>>> I agree with Ruth. This sounds like a user requirement. And the community
>>> should decide on this.
>>> 
>>> Furthermore, the remark 'users might like a new feature, but that doesn't
>>> mean the dev community wants it in the project' smells like measuring with
>>> double standards; as if the meritocratic principle doesn't apply when the
>>> committers don't want it in. Or as if changes always get in, when only the
>>> committers want it.
>>> 
>>> 2012/7/15 Adrian Crum <ad...@sandglass-software.com>
>>>> 
>>> 
>>> Ruth,
>>>> 
>>>> I understand your viewpoint. Personally, I prefer to present my ideas to
>>>> the dev list to see if it is something the dev community wants included
>>>> in
>>>> the project. Users might like a new feature, but that doesn't mean the
>>>> dev
>>>> community wants it in the project. If there was no interest from the dev
>>>> community, then I would offer it as an add-on product and announce it on
>>>> the user list.
>>>> 
>>>> I am also a user, and the design was based on the requirement to monitor
>>>> and control server performance. I suppose I could go to the user list for
>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>> users
>>>> will be free to enhance it in whatever way they please.
>>>> 
>>>> -Adrian
>>>> 
>>>> 
>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>> 
>>>> Hi Adrian:
>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>> "applications" and "stats about services and entities"...those are all
>>>>> indicative of user requirements, not developer requirements.
>>>>> 
>>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>>> and
>>>>> not developers.
>>>>> Just my 2 cents.
>>>>> Regards,
>>>>> Ruth
>>>>> 
>>>>> 
>> 
>> 

Re: Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

Please take some time to understand the purpose of the mailing lists:

https://cwiki.apache.org/OFBADMIN/mailing-lists.html

If a user wants to be involved in the design of OFBiz, then they need to 
be subscribed to the dev list. We do not discuss requirements and 
designs on the user list.

No one is excluded from participation. I proposed an idea. Others 
commented on it. If there had been any objections to including it in the 
project, then I would offer it as an add-on. Excluding a proposal from 
the project does not equal exclusion from participation.

-Adrian

On 7/16/2012 10:11 AM, Pierre Smits wrote:
> You mean excluding parts of the community from participating in the
> decision-taking processes?
>
> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>
>> No, it smells like the current goal of moving things we don't want in the
>> main project to external projects. This type of decision-making has been
>> going on for years.
>>
>> -Adrian
>>
>>
>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>
>>> I agree with Ruth. This sounds like a user requirement. And the community
>>> should decide on this.
>>>
>>> Furthermore, the remark 'users might like a new feature, but that doesn't
>>> mean the dev community wants it in the project' smells like measuring with
>>> double standards; as if the meritocratic principle doesn't apply when the
>>> committers don't want it in. Or as if changes always get in, when only the
>>> committers want it.
>>>
>>> 2012/7/15 Adrian Crum <ad...@sandglass-software.com>
>>>   Ruth,
>>>> I understand your viewpoint. Personally, I prefer to present my ideas to
>>>> the dev list to see if it is something the dev community wants included
>>>> in
>>>> the project. Users might like a new feature, but that doesn't mean the
>>>> dev
>>>> community wants it in the project. If there was no interest from the dev
>>>> community, then I would offer it as an add-on product and announce it on
>>>> the user list.
>>>>
>>>> I am also a user, and the design was based on the requirement to monitor
>>>> and control server performance. I suppose I could go to the user list for
>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>> users
>>>> will be free to enhance it in whatever way they please.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>
>>>>   Hi Adrian:
>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>> "applications" and "stats about services and entities"...those are all
>>>>> indicative of user requirements, not developer requirements.
>>>>>
>>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>>> and
>>>>> not developers.
>>>>> Just my 2 cents.
>>>>> Regards,
>>>>> Ruth
>>>>>
>>>>>
>>

Re: Discussion: Application Metrics Feature

[BJ Freeman <bj...@free-man.net>]

there must be a language barrier here.
it was a suggestion and as I prefaced, I used Pierre's since I did not 
want to find the original. I could have used yours just as well.
It was if you want to get something done, do it yourself type of suggestion.
You add to the drama Ruth.
Not something I enjoy.

Ruth Hoffman sent the following on 7/16/2012 9:25 AM:
> You guys are a hoot! I love reading this list.
> Com'on BJ...this is silly. Don't be so pretentious. Adrian already
> explained his point of view.
> So now I wanna know: What makes you think you can assign "opportunities"
> to Pierre? Or is that also part of the "meritocracy" that comes with
> being a member of this community?
> Best Regards,
> Ruth
> On 7/16/12 11:49 AM, BJ Freeman wrote:
>> I am using this one since it is a long thread and I don't want to read
>> it all.
>> This is a great opportunity for someone, like yourself, to take on the
>> task of informing the user list of activity of the Dev list.
>> Those that think it of interest on the user list can join or read the
>> archive of the dev list.
>>
>> Pierre Smits sent the following on 7/16/2012 2:11 AM:
>>> You mean excluding parts of the community from participating in the
>>> decision-taking processes?
>>>
>>> 2012/7/16 Adrian Crum<ad...@sandglass-software.com>
>>>
>>>> No, it smells like the current goal of moving things we don't want
>>>> in the
>>>> main project to external projects. This type of decision-making has
>>>> been
>>>> going on for years.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>>
>>>>> I agree with Ruth. This sounds like a user requirement. And the
>>>>> community
>>>>> should decide on this.
>>>>>
>>>>> Furthermore, the remark 'users might like a new feature, but that
>>>>> doesn't
>>>>> mean the dev community wants it in the project' smells like
>>>>> measuring with
>>>>> double standards; as if the meritocratic principle doesn't apply
>>>>> when the
>>>>> committers don't want it in. Or as if changes always get in, when
>>>>> only the
>>>>> committers want it.
>>>>>
>>>>> 2012/7/15 Adrian
>>>>> Crum<ad...@sandglass-software.com>
>>>>>
>>>>>>
>>>>>
>>>>> Ruth,
>>>>>>
>>>>>> I understand your viewpoint. Personally, I prefer to present my
>>>>>> ideas to
>>>>>> the dev list to see if it is something the dev community wants
>>>>>> included
>>>>>> in
>>>>>> the project. Users might like a new feature, but that doesn't mean
>>>>>> the
>>>>>> dev
>>>>>> community wants it in the project. If there was no interest from
>>>>>> the dev
>>>>>> community, then I would offer it as an add-on product and announce
>>>>>> it on
>>>>>> the user list.
>>>>>>
>>>>>> I am also a user, and the design was based on the requirement to
>>>>>> monitor
>>>>>> and control server performance. I suppose I could go to the user
>>>>>> list for
>>>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>>>> users
>>>>>> will be free to enhance it in whatever way they please.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>>
>>>>>> Hi Adrian:
>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>> "applications" and "stats about services and entities"...those
>>>>>>> are all
>>>>>>> indicative of user requirements, not developer requirements.
>>>>>>>
>>>>>>> Users should be driving requirements gathering and analysis for
>>>>>>> OFBiz
>>>>>>> and
>>>>>>> not developers.
>>>>>>> Just my 2 cents.
>>>>>>> Regards,
>>>>>>> Ruth
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>
>
>
>

Re: Discussion: Application Metrics Feature

[Ruth Hoffman <rh...@aesolves.com>]

You guys are a hoot! I love reading this list.
Com'on BJ...this is silly. Don't be so pretentious. Adrian already 
explained his point of view.
So now I wanna know: What makes you think you can assign "opportunities" 
to Pierre? Or is that also part of the "meritocracy" that comes with 
being a member of this community?
Best Regards,
Ruth
On 7/16/12 11:49 AM, BJ Freeman wrote:
> I am using this one since it is a long thread and I don't want to read 
> it all.
> This is a great opportunity for someone, like yourself, to take on the 
> task of informing the user list of activity of the Dev list.
> Those that think it of interest on the user list can join or read the 
> archive of the dev list.
>
> Pierre Smits sent the following on 7/16/2012 2:11 AM:
>> You mean excluding parts of the community from participating in the
>> decision-taking processes?
>>
>> 2012/7/16 Adrian Crum<ad...@sandglass-software.com>
>>
>>> No, it smells like the current goal of moving things we don't want 
>>> in the
>>> main project to external projects. This type of decision-making has 
>>> been
>>> going on for years.
>>>
>>> -Adrian
>>>
>>>
>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>
>>>> I agree with Ruth. This sounds like a user requirement. And the 
>>>> community
>>>> should decide on this.
>>>>
>>>> Furthermore, the remark 'users might like a new feature, but that 
>>>> doesn't
>>>> mean the dev community wants it in the project' smells like 
>>>> measuring with
>>>> double standards; as if the meritocratic principle doesn't apply 
>>>> when the
>>>> committers don't want it in. Or as if changes always get in, when 
>>>> only the
>>>> committers want it.
>>>>
>>>> 2012/7/15 Adrian 
>>>> Crum<ad...@sandglass-software.com>
>>>>>
>>>>
>>>>   Ruth,
>>>>>
>>>>> I understand your viewpoint. Personally, I prefer to present my 
>>>>> ideas to
>>>>> the dev list to see if it is something the dev community wants 
>>>>> included
>>>>> in
>>>>> the project. Users might like a new feature, but that doesn't mean 
>>>>> the
>>>>> dev
>>>>> community wants it in the project. If there was no interest from 
>>>>> the dev
>>>>> community, then I would offer it as an add-on product and announce 
>>>>> it on
>>>>> the user list.
>>>>>
>>>>> I am also a user, and the design was based on the requirement to 
>>>>> monitor
>>>>> and control server performance. I suppose I could go to the user 
>>>>> list for
>>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>>> users
>>>>> will be free to enhance it in whatever way they please.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>
>>>>>   Hi Adrian:
>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>> "applications" and "stats about services and entities"...those 
>>>>>> are all
>>>>>> indicative of user requirements, not developer requirements.
>>>>>>
>>>>>> Users should be driving requirements gathering and analysis for 
>>>>>> OFBiz
>>>>>> and
>>>>>> not developers.
>>>>>> Just my 2 cents.
>>>>>> Regards,
>>>>>> Ruth
>>>>>>
>>>>>>
>>>
>>>
>>
>

Re: Discussion: Application Metrics Feature

[BJ Freeman <bj...@free-man.net>]

I am using this one since it is a long thread and I don't want to read 
it all.
This is a great opportunity for someone, like yourself, to take on the 
task of informing the user list of activity of the Dev list.
Those that think it of interest on the user list can join or read the 
archive of the dev list.

Pierre Smits sent the following on 7/16/2012 2:11 AM:
> You mean excluding parts of the community from participating in the
> decision-taking processes?
>
> 2012/7/16 Adrian Crum<ad...@sandglass-software.com>
>
>> No, it smells like the current goal of moving things we don't want in the
>> main project to external projects. This type of decision-making has been
>> going on for years.
>>
>> -Adrian
>>
>>
>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>
>>> I agree with Ruth. This sounds like a user requirement. And the community
>>> should decide on this.
>>>
>>> Furthermore, the remark 'users might like a new feature, but that doesn't
>>> mean the dev community wants it in the project' smells like measuring with
>>> double standards; as if the meritocratic principle doesn't apply when the
>>> committers don't want it in. Or as if changes always get in, when only the
>>> committers want it.
>>>
>>> 2012/7/15 Adrian Crum<ad...@sandglass-software.com>
>>>>
>>>
>>>   Ruth,
>>>>
>>>> I understand your viewpoint. Personally, I prefer to present my ideas to
>>>> the dev list to see if it is something the dev community wants included
>>>> in
>>>> the project. Users might like a new feature, but that doesn't mean the
>>>> dev
>>>> community wants it in the project. If there was no interest from the dev
>>>> community, then I would offer it as an add-on product and announce it on
>>>> the user list.
>>>>
>>>> I am also a user, and the design was based on the requirement to monitor
>>>> and control server performance. I suppose I could go to the user list for
>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>> users
>>>> will be free to enhance it in whatever way they please.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>
>>>>   Hi Adrian:
>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>> "applications" and "stats about services and entities"...those are all
>>>>> indicative of user requirements, not developer requirements.
>>>>>
>>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>>> and
>>>>> not developers.
>>>>> Just my 2 cents.
>>>>> Regards,
>>>>> Ruth
>>>>>
>>>>>
>>
>>
>

Re: Discussion: Application Metrics Feature

[Pierre Smits <pi...@gmail.com>]

You mean excluding parts of the community from participating in the
decision-taking processes?

2012/7/16 Adrian Crum <ad...@sandglass-software.com>

> No, it smells like the current goal of moving things we don't want in the
> main project to external projects. This type of decision-making has been
> going on for years.
>
> -Adrian
>
>
> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>
>> I agree with Ruth. This sounds like a user requirement. And the community
>> should decide on this.
>>
>> Furthermore, the remark 'users might like a new feature, but that doesn't
>> mean the dev community wants it in the project' smells like measuring with
>> double standards; as if the meritocratic principle doesn't apply when the
>> committers don't want it in. Or as if changes always get in, when only the
>> committers want it.
>>
>> 2012/7/15 Adrian Crum <ad...@sandglass-software.com>
>> >
>>
>>  Ruth,
>>>
>>> I understand your viewpoint. Personally, I prefer to present my ideas to
>>> the dev list to see if it is something the dev community wants included
>>> in
>>> the project. Users might like a new feature, but that doesn't mean the
>>> dev
>>> community wants it in the project. If there was no interest from the dev
>>> community, then I would offer it as an add-on product and announce it on
>>> the user list.
>>>
>>> I am also a user, and the design was based on the requirement to monitor
>>> and control server performance. I suppose I could go to the user list for
>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>> users
>>> will be free to enhance it in whatever way they please.
>>>
>>> -Adrian
>>>
>>>
>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>
>>>  Hi Adrian:
>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>> "applications" and "stats about services and entities"...those are all
>>>> indicative of user requirements, not developer requirements.
>>>>
>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>> and
>>>> not developers.
>>>> Just my 2 cents.
>>>> Regards,
>>>> Ruth
>>>>
>>>>
>
>

Re: Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

No, it smells like the current goal of moving things we don't want in 
the main project to external projects. This type of decision-making has 
been going on for years.

-Adrian

On 7/16/2012 9:45 AM, Pierre Smits wrote:
> I agree with Ruth. This sounds like a user requirement. And the community
> should decide on this.
>
> Furthermore, the remark 'users might like a new feature, but that doesn't
> mean the dev community wants it in the project' smells like measuring with
> double standards; as if the meritocratic principle doesn't apply when the
> committers don't want it in. Or as if changes always get in, when only the
> committers want it.
>
> 2012/7/15 Adrian Crum <ad...@sandglass-software.com>
>
>> Ruth,
>>
>> I understand your viewpoint. Personally, I prefer to present my ideas to
>> the dev list to see if it is something the dev community wants included in
>> the project. Users might like a new feature, but that doesn't mean the dev
>> community wants it in the project. If there was no interest from the dev
>> community, then I would offer it as an add-on product and announce it on
>> the user list.
>>
>> I am also a user, and the design was based on the requirement to monitor
>> and control server performance. I suppose I could go to the user list for
>> more ideas, but the code I'm planning to commit is pretty basic, and users
>> will be free to enhance it in whatever way they please.
>>
>> -Adrian
>>
>>
>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>
>>> Hi Adrian:
>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>> "applications" and "stats about services and entities"...those are all
>>> indicative of user requirements, not developer requirements.
>>>
>>> Users should be driving requirements gathering and analysis for OFBiz and
>>> not developers.
>>> Just my 2 cents.
>>> Regards,
>>> Ruth
>>>

Re: Discussion: Application Metrics Feature

[Pierre Smits <pi...@gmail.com>]

I agree with Ruth. This sounds like a user requirement. And the community
should decide on this.

Furthermore, the remark 'users might like a new feature, but that doesn't
mean the dev community wants it in the project' smells like measuring with
double standards; as if the meritocratic principle doesn't apply when the
committers don't want it in. Or as if changes always get in, when only the
committers want it.

2012/7/15 Adrian Crum <ad...@sandglass-software.com>

> Ruth,
>
> I understand your viewpoint. Personally, I prefer to present my ideas to
> the dev list to see if it is something the dev community wants included in
> the project. Users might like a new feature, but that doesn't mean the dev
> community wants it in the project. If there was no interest from the dev
> community, then I would offer it as an add-on product and announce it on
> the user list.
>
> I am also a user, and the design was based on the requirement to monitor
> and control server performance. I suppose I could go to the user list for
> more ideas, but the code I'm planning to commit is pretty basic, and users
> will be free to enhance it in whatever way they please.
>
> -Adrian
>
>
> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>
>> Hi Adrian:
>> Shouldn't this be discussed on the "user" list? IMHO Words like
>> "applications" and "stats about services and entities"...those are all
>> indicative of user requirements, not developer requirements.
>>
>> Users should be driving requirements gathering and analysis for OFBiz and
>> not developers.
>> Just my 2 cents.
>> Regards,
>> Ruth
>>
>

Re: Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

Ruth,

I understand your viewpoint. Personally, I prefer to present my ideas to 
the dev list to see if it is something the dev community wants included 
in the project. Users might like a new feature, but that doesn't mean 
the dev community wants it in the project. If there was no interest from 
the dev community, then I would offer it as an add-on product and 
announce it on the user list.

I am also a user, and the design was based on the requirement to monitor 
and control server performance. I suppose I could go to the user list 
for more ideas, but the code I'm planning to commit is pretty basic, and 
users will be free to enhance it in whatever way they please.

-Adrian

On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
> Hi Adrian:
> Shouldn't this be discussed on the "user" list? IMHO Words like 
> "applications" and "stats about services and entities"...those are all 
> indicative of user requirements, not developer requirements.
>
> Users should be driving requirements gathering and analysis for OFBiz 
> and not developers.
> Just my 2 cents.
> Regards,
> Ruth
> On 7/15/12 4:41 AM, Adrian Crum wrote:
>> On 7/14/2012 3:40 PM, Jacopo Cappellato wrote:
>>> On Jul 14, 2012, at 4:18 PM, Adrian Crum wrote:
>>>
>>>> At first glance, this might seem like a duplication of 
>>>> ServerHitBin.java, but it isn't. The metrics Java code will be in 
>>>> the base component, and it is designed to be used to measure any 
>>>> part of the project, not just web app requests.
>>>>
>>>> -Adrian
>>>>
>>> I know that there are features in the ServerHitBin class to gather 
>>> stats about services and entities, but I don't remember how they are 
>>> implemented and if they are fully used.
>>>
>>> Jacopo
>>
>> The ServerHitBin entity and service methods are not used currently. 
>> Metrics could be kept for entities, but I don't think that they would 
>> be meaningful - so I didn't add them. If someone comes up with a need 
>> for entity metrics, then the capability can be added easily.
>>
>> In a nutshell, the ServerHitBin code is quite heavy - it uses the 
>> entity engine to store the metrics. The design I used is from SEDA - 
>> it is meant to be used in a "feedback loop" that is used to control 
>> web application response times, so it is small and fast. Also, 
>> ServerHitBin stats are kept for every request, but the metrics code 
>> is more strategic - you maintain metrics only in the areas you are 
>> concerned with.
>>
>> -Adrian
>>
>>
>
>

Re: Discussion: Application Metrics Feature

[Ruth Hoffman <rh...@aesolves.com>]

Hi Adrian:
Shouldn't this be discussed on the "user" list? IMHO Words like 
"applications" and "stats about services and entities"...those are all 
indicative of user requirements, not developer requirements.

Users should be driving requirements gathering and analysis for OFBiz 
and not developers.
Just my 2 cents.
Regards,
Ruth
On 7/15/12 4:41 AM, Adrian Crum wrote:
> On 7/14/2012 3:40 PM, Jacopo Cappellato wrote:
>> On Jul 14, 2012, at 4:18 PM, Adrian Crum wrote:
>>
>>> At first glance, this might seem like a duplication of 
>>> ServerHitBin.java, but it isn't. The metrics Java code will be in 
>>> the base component, and it is designed to be used to measure any 
>>> part of the project, not just web app requests.
>>>
>>> -Adrian
>>>
>> I know that there are features in the ServerHitBin class to gather 
>> stats about services and entities, but I don't remember how they are 
>> implemented and if they are fully used.
>>
>> Jacopo
>
> The ServerHitBin entity and service methods are not used currently. 
> Metrics could be kept for entities, but I don't think that they would 
> be meaningful - so I didn't add them. If someone comes up with a need 
> for entity metrics, then the capability can be added easily.
>
> In a nutshell, the ServerHitBin code is quite heavy - it uses the 
> entity engine to store the metrics. The design I used is from SEDA - 
> it is meant to be used in a "feedback loop" that is used to control 
> web application response times, so it is small and fast. Also, 
> ServerHitBin stats are kept for every request, but the metrics code is 
> more strategic - you maintain metrics only in the areas you are 
> concerned with.
>
> -Adrian
>
>

Re: Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

On 7/14/2012 3:40 PM, Jacopo Cappellato wrote:
> On Jul 14, 2012, at 4:18 PM, Adrian Crum wrote:
>
>> At first glance, this might seem like a duplication of ServerHitBin.java, but it isn't. The metrics Java code will be in the base component, and it is designed to be used to measure any part of the project, not just web app requests.
>>
>> -Adrian
>>
> I know that there are features in the ServerHitBin class to gather stats about services and entities, but I don't remember how they are implemented and if they are fully used.
>
> Jacopo

The ServerHitBin entity and service methods are not used currently. 
Metrics could be kept for entities, but I don't think that they would be 
meaningful - so I didn't add them. If someone comes up with a need for 
entity metrics, then the capability can be added easily.

In a nutshell, the ServerHitBin code is quite heavy - it uses the entity 
engine to store the metrics. The design I used is from SEDA - it is 
meant to be used in a "feedback loop" that is used to control web 
application response times, so it is small and fast. Also, ServerHitBin 
stats are kept for every request, but the metrics code is more strategic 
- you maintain metrics only in the areas you are concerned with.

-Adrian

Re: Discussion: Application Metrics Feature

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Jul 14, 2012, at 4:18 PM, Adrian Crum wrote:

> At first glance, this might seem like a duplication of ServerHitBin.java, but it isn't. The metrics Java code will be in the base component, and it is designed to be used to measure any part of the project, not just web app requests.
> 
> -Adrian
> 

I know that there are features in the ServerHitBin class to gather stats about services and entities, but I don't remember how they are implemented and if they are fully used.

Jacopo

Re: Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

At first glance, this might seem like a duplication of 
ServerHitBin.java, but it isn't. The metrics Java code will be in the 
base component, and it is designed to be used to measure any part of the 
project, not just web app requests.

-Adrian

On 7/14/2012 12:28 PM, Jacopo Cappellato wrote:
> Adrian,
>
> thank you for the clear description and proposal; I like it very much and I would be happy to see it in OFBiz.
>
> Regards,
>
> Jacopo
>
> On Jul 14, 2012, at 12:38 PM, Adrian Crum wrote:
>
>> I have an application metrics feature working on my local copy and I was wondering if there would be any interest in including it in the project.
>>
>> A metric is a measure of average execution time. Each metric is given a unique name.
>>
>> I modified the control servlet and service dispatcher to use metrics. To add a metric to a request, just include an XML element:
>>
>> <metric name="URL: webtools/main" />
>>
>> to the request map and the average response time for the URL will be maintained. Likewise, to add a metric to a service, just include an XML element:
>>
>> <metric name="Service: createMaintsFromTimeInterval" />
>>
>> to the service definition and the average execution time for the service will be maintained.
>>
>> Metrics are kept in memory. There is a service to retrieve all metrics. There is also a Web Tools page to view all metrics.
>>
>> A heartbeat server could retrieve the metrics to check on server load or to provide histograms.
>>
>> The metric element has an optional threshold attribute, so some action could be taken when the metric crosses a threshold. For example, in the following request map:
>>
>> <request-map uri="ViewMetrics">
>>     <security https="true" auth="true"/>
>>     <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>     <response name="success" type="view" value="ViewMetrics"/>
>>     <response name="threshold-exceeded" type="view" value="ServerBusy"/><!-- displays a friendly 'server busy' page -->
>> </request-map>
>>
>> the ServerBusy view would be rendered if the average response time exceeded 1000 mS. This can be useful for providing a lively web experience on a heavy-traffic web page.
>>
>> The service dispatcher does not use the threshold. I could not think of a use case where service behavior should be modified based on average execution time.
>>
>> The metrics code is very small - two java files. Also, the modifications to the webapp component and service component are very small.
>>
>> What do you think?
>>
>> -Adrian
>>

Re: Discussion: Application Metrics Feature

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Adrian,

thank you for the clear description and proposal; I like it very much and I would be happy to see it in OFBiz.

Regards,

Jacopo

On Jul 14, 2012, at 12:38 PM, Adrian Crum wrote:

> I have an application metrics feature working on my local copy and I was wondering if there would be any interest in including it in the project.
> 
> A metric is a measure of average execution time. Each metric is given a unique name.
> 
> I modified the control servlet and service dispatcher to use metrics. To add a metric to a request, just include an XML element:
> 
> <metric name="URL: webtools/main" />
> 
> to the request map and the average response time for the URL will be maintained. Likewise, to add a metric to a service, just include an XML element:
> 
> <metric name="Service: createMaintsFromTimeInterval" />
> 
> to the service definition and the average execution time for the service will be maintained.
> 
> Metrics are kept in memory. There is a service to retrieve all metrics. There is also a Web Tools page to view all metrics.
> 
> A heartbeat server could retrieve the metrics to check on server load or to provide histograms.
> 
> The metric element has an optional threshold attribute, so some action could be taken when the metric crosses a threshold. For example, in the following request map:
> 
> <request-map uri="ViewMetrics">
>    <security https="true" auth="true"/>
>    <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>    <response name="success" type="view" value="ViewMetrics"/>
>    <response name="threshold-exceeded" type="view" value="ServerBusy"/><!-- displays a friendly 'server busy' page -->
> </request-map>
> 
> the ServerBusy view would be rendered if the average response time exceeded 1000 mS. This can be useful for providing a lively web experience on a heavy-traffic web page.
> 
> The service dispatcher does not use the threshold. I could not think of a use case where service behavior should be modified based on average execution time.
> 
> The metrics code is very small - two java files. Also, the modifications to the webapp component and service component are very small.
> 
> What do you think?
> 
> -Adrian
> 

Re: Discussion: Application Metrics Feature

[Michael Brohl <of...@brohl.net>]

Hi Adrian,

that sounds like an interesting feature for OFBiz.
I would like to have it available in the project.

Thanks and regards,

Michael

Am 14.07.2012 12:38, schrieb Adrian Crum:
> I have an application metrics feature working on my local copy and I
> was wondering if there would be any interest in including it in the
> project.
>
> A metric is a measure of average execution time. Each metric is given
> a unique name.
>
> I modified the control servlet and service dispatcher to use metrics.
> To add a metric to a request, just include an XML element:
>
> <metric name="URL: webtools/main" />
>
> to the request map and the average response time for the URL will be
> maintained. Likewise, to add a metric to a service, just include an
> XML element:
>
> <metric name="Service: createMaintsFromTimeInterval" />
>
> to the service definition and the average execution time for the
> service will be maintained.
>
> Metrics are kept in memory. There is a service to retrieve all
> metrics. There is also a Web Tools page to view all metrics.
>
> A heartbeat server could retrieve the metrics to check on server load
> or to provide histograms.
>
> The metric element has an optional threshold attribute, so some action
> could be taken when the metric crosses a threshold. For example, in
> the following request map:
>
> <request-map uri="ViewMetrics">
>     <security https="true" auth="true"/>
>     <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>     <response name="success" type="view" value="ViewMetrics"/>
>     <response name="threshold-exceeded" type="view"
> value="ServerBusy"/><!-- displays a friendly 'server busy' page -->
> </request-map>
>
> the ServerBusy view would be rendered if the average response time
> exceeded 1000 mS. This can be useful for providing a lively web
> experience on a heavy-traffic web page.
>
> The service dispatcher does not use the threshold. I could not think
> of a use case where service behavior should be modified based on
> average execution time.
>
> The metrics code is very small - two java files. Also, the
> modifications to the webapp component and service component are very
> small.
>
> What do you think?
>
> -Adrian
>

Re: Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

Please take time to understand how the community works:

http://www.apache.org/foundation/voting.html

Commits are not reverted simply because a user asks for it.

-Adrian

On 7/16/2012 12:26 PM, Pierre Smits wrote:
> Now go do like you said you would do. Or is your word not your bond?
>
> 2012/7/16 Pierre Smits <pi...@gmail.com>
>
>> You didn't state any conditions for reverting it.
>>
>>
>> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>>
>>> For what reason? Is there a flaw in the design?
>>>
>>> -Adrian
>>>
>>>
>>> On 7/16/2012 12:16 PM, Pierre Smits wrote:
>>>
>>>> Then I object to having it in trunk before the outcome of this
>>>> discussion.
>>>>
>>>> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>>>>   We are still discussing it, and if there are any objections I can revert
>>>>> the commit.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 7/16/2012 12:04 PM, Pierre Smits wrote:
>>>>>
>>>>>   You make it sound like it is still open for debate. However, you
>>>>>> committed
>>>>>> this new feature to trunk. In barely under 30 hours after you started
>>>>>> this
>>>>>> mail thread. If you were truly seeking input from the community, you
>>>>>> could
>>>>>> and should have waited longer and for the outcome.
>>>>>>
>>>>>>
>>>>>>
>>>

Re: Discussion: Application Metrics Feature

[Pierre Smits <pi...@gmail.com>]

Now go do like you said you would do. Or is your word not your bond?

2012/7/16 Pierre Smits <pi...@gmail.com>

> You didn't state any conditions for reverting it.
>
>
> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>
>> For what reason? Is there a flaw in the design?
>>
>> -Adrian
>>
>>
>> On 7/16/2012 12:16 PM, Pierre Smits wrote:
>>
>>> Then I object to having it in trunk before the outcome of this
>>> discussion.
>>>
>>> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>>> >
>>>
>>>  We are still discussing it, and if there are any objections I can revert
>>>> the commit.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/16/2012 12:04 PM, Pierre Smits wrote:
>>>>
>>>>  You make it sound like it is still open for debate. However, you
>>>>> committed
>>>>> this new feature to trunk. In barely under 30 hours after you started
>>>>> this
>>>>> mail thread. If you were truly seeking input from the community, you
>>>>> could
>>>>> and should have waited longer and for the outcome.
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>

Re: Discussion: Application Metrics Feature

[Pierre Smits <pi...@gmail.com>]

You didn't state any conditions for reverting it.

2012/7/16 Adrian Crum <ad...@sandglass-software.com>

> For what reason? Is there a flaw in the design?
>
> -Adrian
>
>
> On 7/16/2012 12:16 PM, Pierre Smits wrote:
>
>> Then I object to having it in trunk before the outcome of this discussion.
>>
>> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>> >
>>
>>  We are still discussing it, and if there are any objections I can revert
>>> the commit.
>>>
>>> -Adrian
>>>
>>>
>>> On 7/16/2012 12:04 PM, Pierre Smits wrote:
>>>
>>>  You make it sound like it is still open for debate. However, you
>>>> committed
>>>> this new feature to trunk. In barely under 30 hours after you started
>>>> this
>>>> mail thread. If you were truly seeking input from the community, you
>>>> could
>>>> and should have waited longer and for the outcome.
>>>>
>>>>
>>>>
>>>
>
>

Re: Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

For what reason? Is there a flaw in the design?

-Adrian

On 7/16/2012 12:16 PM, Pierre Smits wrote:
> Then I object to having it in trunk before the outcome of this discussion.
>
> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>
>> We are still discussing it, and if there are any objections I can revert
>> the commit.
>>
>> -Adrian
>>
>>
>> On 7/16/2012 12:04 PM, Pierre Smits wrote:
>>
>>> You make it sound like it is still open for debate. However, you committed
>>> this new feature to trunk. In barely under 30 hours after you started this
>>> mail thread. If you were truly seeking input from the community, you could
>>> and should have waited longer and for the outcome.
>>>
>>>
>>

Re: Discussion: Application Metrics Feature

[Pierre Smits <pi...@gmail.com>]

Then I object to having it in trunk before the outcome of this discussion.

2012/7/16 Adrian Crum <ad...@sandglass-software.com>

> We are still discussing it, and if there are any objections I can revert
> the commit.
>
> -Adrian
>
>
> On 7/16/2012 12:04 PM, Pierre Smits wrote:
>
>> You make it sound like it is still open for debate. However, you committed
>> this new feature to trunk. In barely under 30 hours after you started this
>> mail thread. If you were truly seeking input from the community, you could
>> and should have waited longer and for the outcome.
>>
>>
>
>

Re: Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

We are still discussing it, and if there are any objections I can revert 
the commit.

-Adrian

On 7/16/2012 12:04 PM, Pierre Smits wrote:
> You make it sound like it is still open for debate. However, you committed
> this new feature to trunk. In barely under 30 hours after you started this
> mail thread. If you were truly seeking input from the community, you could
> and should have waited longer and for the outcome.
>

Re: Discussion: Application Metrics Feature

[Pierre Smits <pi...@gmail.com>]

You make it sound like it is still open for debate. However, you committed
this new feature to trunk. In barely under 30 hours after you started this
mail thread. If you were truly seeking input from the community, you could
and should have waited longer and for the outcome.

Re: Discussion: Application Metrics Feature

[BJ Freeman <bj...@free-man.net>]

just for clarification this is not a new features map, but a Dev 
consideration map. so people can see what has been considered and the 
outcome.

BJ Freeman sent the following on 7/16/2012 3:54 AM:
> that is true, however a month from now it will be lost and will have to
> be searched.
> So you start by putting you proposal on the wiki then link in the email
> for discussion.
> once the discussion is completed it is put on the wiki with a link to a
> page of the discussion. and a synopsis of the result of the discussion.
>
> Adrian Crum sent the following on 7/16/2012 3:45 AM:
>> Having a Wiki page that describes the new feature would be great, but it
>> needs to be created after the commit and some review. Creating a Wiki
>> page before there is any interest expressed in the proposal could be a
>> waste of time. So, I cover the goal, scope, and effect on the current
>> design in the emailed proposal.
>>
>> -Adrian
>>
>> On 7/16/2012 11:32 AM, BJ Freeman wrote:
>>> What would be great is if we had a Dev map that showed a design plan
>>> The Goal, Scope, and effect on the current design.
>>> having all these in one place on the wiki would help in over all design.
>>> my 2 cents.
>>>
>>> Adrian Crum sent the following on 7/14/2012 3:38 AM:
>>>> I have an application metrics feature working on my local copy and I
>>>> was
>>>> wondering if there would be any interest in including it in the
>>>> project.
>>>>
>>>> A metric is a measure of average execution time. Each metric is given a
>>>> unique name.
>>>>
>>>> I modified the control servlet and service dispatcher to use
>>>> metrics. To
>>>> add a metric to a request, just include an XML element:
>>>>
>>>> <metric name="URL: webtools/main" />
>>>>
>>>> to the request map and the average response time for the URL will be
>>>> maintained. Likewise, to add a metric to a service, just include an XML
>>>> element:
>>>>
>>>> <metric name="Service: createMaintsFromTimeInterval" />
>>>>
>>>> to the service definition and the average execution time for the
>>>> service
>>>> will be maintained.
>>>>
>>>> Metrics are kept in memory. There is a service to retrieve all metrics.
>>>> There is also a Web Tools page to view all metrics.
>>>>
>>>> A heartbeat server could retrieve the metrics to check on server
>>>> load or
>>>> to provide histograms.
>>>>
>>>> The metric element has an optional threshold attribute, so some action
>>>> could be taken when the metric crosses a threshold. For example, in the
>>>> following request map:
>>>>
>>>> <request-map uri="ViewMetrics">
>>>> <security https="true" auth="true"/>
>>>> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>>> <response name="success" type="view" value="ViewMetrics"/>
>>>> <response name="threshold-exceeded" type="view"
>>>> value="ServerBusy"/><!--
>>>> displays a friendly 'server busy' page -->
>>>> </request-map>
>>>>
>>>> the ServerBusy view would be rendered if the average response time
>>>> exceeded 1000 mS. This can be useful for providing a lively web
>>>> experience on a heavy-traffic web page.
>>>>
>>>> The service dispatcher does not use the threshold. I could not think of
>>>> a use case where service behavior should be modified based on average
>>>> execution time.
>>>>
>>>> The metrics code is very small - two java files. Also, the
>>>> modifications
>>>> to the webapp component and service component are very small.
>>>>
>>>> What do you think?
>>>>
>>>> -Adrian
>>>>
>>>>
>>
>>
>>
>

Re: Discussion: Application Metrics Feature

[Jacques Le Roux <ja...@les7arts.com>]

From: "Pierre Smits" <pi...@gmail.com>
> Adrian,
>
> I want you and any other committer to follow the procedures and guidelines
> established by the Apache foundation. If you feel that you aren't obliged
> to adhere to them you shouldn't be a committer.
>
> Jacques,
>
> The Apache document on voting (which has been referred to) clearly states
> that voting should take place for at least 72 hours to let everybody in the
> community have his or her say. Also, although the document also states that
> only PMC members have a binding vote the expressions made by other
> community members should be considered as well.
> Furthermore, Adrian explicitly said 'any objection'. Thus, inviting any
> OFBiz member participating in development. If Adrian kept to his word, we
> would have seen the commits reverted. And not have this discussion.

Vote is only when no consensus is found. I can agree Adrian was a bit short on time, else there was a consensus it seems (note the 
number of +1), apart Ruth and you. Not even sure Ruth is against actually.

Jacques

>
>
> 2012/7/16 Adrian Crum <ad...@sandglass-software.com>
>
>> Pierre,
>>
>> Please stop wasting everyone's time. We have tried to explain to you how
>> the community works. If it is that difficult for you to grasp, then perhaps
>> you should just let it go.
>>
>> -Adrian
>>
>>
>> On 7/16/2012 1:02 PM, Pierre Smits wrote:
>>
>>> There you have it. This commit should and must be reverted because Apache
>>> procedures weren't followed. I just reminded you of that.
>>>
>>> When you asked for the opinions of the community you solicited a vote.
>>> Thus
>>> procedures should be followed. Or do you feel that you can implement
>>> changes without following procedures?
>>>
>>>
>>> 2012/7/16 Jacques Le Roux <ja...@les7arts.com>
>>>
>>>  As we already agreed long ago, the flow should roughly be:
>>>> Dev ML proposition  => dev ML dicusssion => if tiny change and community
>>>> consensus then code and commit else if not tiny change (I let apart no
>>>> consensys as it's obvious) => Jira + patch => reviews (not only from
>>>> committers, we pray developers not being committers to review as well, a
>>>> good way to become committers BTW) => if agreement then commit => if
>>>> necessary and possible create a wiki page to explain the feature
>>>>
>>>> Did I miss something? Ha maybe vote. In a rare cases where there is no
>>>> consensus (as a community we should always try to get to a consensus) and
>>>> the community thinks a vote is needed.
>>>>
>>>> Please refer to ASF documentation for more http://www.apache.org/**
>>>> foundation/voting.html <http://www.apache.org/**foundation/voting.html<http://www.apache.org/foundation/voting.html>
>>>> >
>>>>
>>>>
>>>> So the preliminary doc (mostly requirements, etc) should be in Jira, then
>>>> completed in wiki
>>>>
>>>> David also created a wiki space for "OFBiz Requirements and Designs":
>>>> https://cwiki.apache.org/****confluence/display/OFBREQDES/****Home<https://cwiki.apache.org/**confluence/display/OFBREQDES/**Home>
>>>> <https://cwiki.apache.**org/confluence/display/**OFBREQDES/Home<https://cwiki.apache.org/confluence/display/OFBREQDES/Home>
>>>> >.
>>>>
>>>> This could be used in BJ's spirit for larger tasks...
>>>>
>>>> Jacques
>>>>
>>>> From: "BJ Freeman" <bj...@free-man.net>
>>>>
>>>>   that is true, however a month from now it will be lost and will have to
>>>>
>>>>> be searched.
>>>>> So you start by putting you proposal on the wiki then link in the email
>>>>> for discussion.
>>>>> once the discussion is completed it is put on the wiki with a link to a
>>>>> page of the discussion. and a synopsis of the result of the discussion.
>>>>>
>>>>> Adrian Crum sent the following on 7/16/2012 3:45 AM:
>>>>>
>>>>>  Having a Wiki page that describes the new feature would be great, but
>>>>>> it
>>>>>> needs to be created after the commit and some review. Creating a Wiki
>>>>>> page before there is any interest expressed in the proposal could be a
>>>>>> waste of time. So, I cover the goal, scope, and effect on the current
>>>>>> design in the emailed proposal.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 7/16/2012 11:32 AM, BJ Freeman wrote:
>>>>>>
>>>>>>  What would be great is if we had a Dev map that showed a design plan
>>>>>>> The Goal, Scope, and effect on the current design.
>>>>>>> having all these in one place on the wiki would help in over all
>>>>>>> design.
>>>>>>> my 2 cents.
>>>>>>>
>>>>>>> Adrian Crum sent the following on 7/14/2012 3:38 AM:
>>>>>>>
>>>>>>>  I have an application metrics feature working on my local copy and I
>>>>>>>> was
>>>>>>>> wondering if there would be any interest in including it in the
>>>>>>>> project.
>>>>>>>>
>>>>>>>> A metric is a measure of average execution time. Each metric is
>>>>>>>> given a
>>>>>>>> unique name.
>>>>>>>>
>>>>>>>> I modified the control servlet and service dispatcher to use metrics.
>>>>>>>> To
>>>>>>>> add a metric to a request, just include an XML element:
>>>>>>>>
>>>>>>>> <metric name="URL: webtools/main" />
>>>>>>>>
>>>>>>>> to the request map and the average response time for the URL will be
>>>>>>>> maintained. Likewise, to add a metric to a service, just include an
>>>>>>>> XML
>>>>>>>> element:
>>>>>>>>
>>>>>>>> <metric name="Service: createMaintsFromTimeInterval" />
>>>>>>>>
>>>>>>>> to the service definition and the average execution time for the
>>>>>>>> service
>>>>>>>> will be maintained.
>>>>>>>>
>>>>>>>> Metrics are kept in memory. There is a service to retrieve all
>>>>>>>> metrics.
>>>>>>>> There is also a Web Tools page to view all metrics.
>>>>>>>>
>>>>>>>> A heartbeat server could retrieve the metrics to check on server load
>>>>>>>> or
>>>>>>>> to provide histograms.
>>>>>>>>
>>>>>>>> The metric element has an optional threshold attribute, so some
>>>>>>>> action
>>>>>>>> could be taken when the metric crosses a threshold. For example, in
>>>>>>>> the
>>>>>>>> following request map:
>>>>>>>>
>>>>>>>> <request-map uri="ViewMetrics">
>>>>>>>> <security https="true" auth="true"/>
>>>>>>>> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>>>>>>> <response name="success" type="view" value="ViewMetrics"/>
>>>>>>>> <response name="threshold-exceeded" type="view"
>>>>>>>> value="ServerBusy"/><!--
>>>>>>>> displays a friendly 'server busy' page -->
>>>>>>>> </request-map>
>>>>>>>>
>>>>>>>> the ServerBusy view would be rendered if the average response time
>>>>>>>> exceeded 1000 mS. This can be useful for providing a lively web
>>>>>>>> experience on a heavy-traffic web page.
>>>>>>>>
>>>>>>>> The service dispatcher does not use the threshold. I could not think
>>>>>>>> of
>>>>>>>> a use case where service behavior should be modified based on average
>>>>>>>> execution time.
>>>>>>>>
>>>>>>>> The metrics code is very small - two java files. Also, the
>>>>>>>> modifications
>>>>>>>> to the webapp component and service component are very small.
>>>>>>>>
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>
>>
> 

Re: Discussion: Application Metrics Feature

[Pierre Smits <pi...@gmail.com>]

Adrian,

I want you and any other committer to follow the procedures and guidelines
established by the Apache foundation. If you feel that you aren't obliged
to adhere to them you shouldn't be a committer.

Jacques,

The Apache document on voting (which has been referred to) clearly states
that voting should take place for at least 72 hours to let everybody in the
community have his or her say. Also, although the document also states that
only PMC members have a binding vote the expressions made by other
community members should be considered as well.
Furthermore, Adrian explicitly said 'any objection'. Thus, inviting any
OFBiz member participating in development. If Adrian kept to his word, we
would have seen the commits reverted. And not have this discussion.



2012/7/16 Adrian Crum <ad...@sandglass-software.com>

> Pierre,
>
> Please stop wasting everyone's time. We have tried to explain to you how
> the community works. If it is that difficult for you to grasp, then perhaps
> you should just let it go.
>
> -Adrian
>
>
> On 7/16/2012 1:02 PM, Pierre Smits wrote:
>
>> There you have it. This commit should and must be reverted because Apache
>> procedures weren't followed. I just reminded you of that.
>>
>> When you asked for the opinions of the community you solicited a vote.
>> Thus
>> procedures should be followed. Or do you feel that you can implement
>> changes without following procedures?
>>
>>
>> 2012/7/16 Jacques Le Roux <ja...@les7arts.com>
>>
>>  As we already agreed long ago, the flow should roughly be:
>>> Dev ML proposition  => dev ML dicusssion => if tiny change and community
>>> consensus then code and commit else if not tiny change (I let apart no
>>> consensys as it's obvious) => Jira + patch => reviews (not only from
>>> committers, we pray developers not being committers to review as well, a
>>> good way to become committers BTW) => if agreement then commit => if
>>> necessary and possible create a wiki page to explain the feature
>>>
>>> Did I miss something? Ha maybe vote. In a rare cases where there is no
>>> consensus (as a community we should always try to get to a consensus) and
>>> the community thinks a vote is needed.
>>>
>>> Please refer to ASF documentation for more http://www.apache.org/**
>>> foundation/voting.html <http://www.apache.org/**foundation/voting.html<http://www.apache.org/foundation/voting.html>
>>> >
>>>
>>>
>>> So the preliminary doc (mostly requirements, etc) should be in Jira, then
>>> completed in wiki
>>>
>>> David also created a wiki space for "OFBiz Requirements and Designs":
>>> https://cwiki.apache.org/****confluence/display/OFBREQDES/****Home<https://cwiki.apache.org/**confluence/display/OFBREQDES/**Home>
>>> <https://cwiki.apache.**org/confluence/display/**OFBREQDES/Home<https://cwiki.apache.org/confluence/display/OFBREQDES/Home>
>>> >.
>>>
>>> This could be used in BJ's spirit for larger tasks...
>>>
>>> Jacques
>>>
>>> From: "BJ Freeman" <bj...@free-man.net>
>>>
>>>   that is true, however a month from now it will be lost and will have to
>>>
>>>> be searched.
>>>> So you start by putting you proposal on the wiki then link in the email
>>>> for discussion.
>>>> once the discussion is completed it is put on the wiki with a link to a
>>>> page of the discussion. and a synopsis of the result of the discussion.
>>>>
>>>> Adrian Crum sent the following on 7/16/2012 3:45 AM:
>>>>
>>>>  Having a Wiki page that describes the new feature would be great, but
>>>>> it
>>>>> needs to be created after the commit and some review. Creating a Wiki
>>>>> page before there is any interest expressed in the proposal could be a
>>>>> waste of time. So, I cover the goal, scope, and effect on the current
>>>>> design in the emailed proposal.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 7/16/2012 11:32 AM, BJ Freeman wrote:
>>>>>
>>>>>  What would be great is if we had a Dev map that showed a design plan
>>>>>> The Goal, Scope, and effect on the current design.
>>>>>> having all these in one place on the wiki would help in over all
>>>>>> design.
>>>>>> my 2 cents.
>>>>>>
>>>>>> Adrian Crum sent the following on 7/14/2012 3:38 AM:
>>>>>>
>>>>>>  I have an application metrics feature working on my local copy and I
>>>>>>> was
>>>>>>> wondering if there would be any interest in including it in the
>>>>>>> project.
>>>>>>>
>>>>>>> A metric is a measure of average execution time. Each metric is
>>>>>>> given a
>>>>>>> unique name.
>>>>>>>
>>>>>>> I modified the control servlet and service dispatcher to use metrics.
>>>>>>> To
>>>>>>> add a metric to a request, just include an XML element:
>>>>>>>
>>>>>>> <metric name="URL: webtools/main" />
>>>>>>>
>>>>>>> to the request map and the average response time for the URL will be
>>>>>>> maintained. Likewise, to add a metric to a service, just include an
>>>>>>> XML
>>>>>>> element:
>>>>>>>
>>>>>>> <metric name="Service: createMaintsFromTimeInterval" />
>>>>>>>
>>>>>>> to the service definition and the average execution time for the
>>>>>>> service
>>>>>>> will be maintained.
>>>>>>>
>>>>>>> Metrics are kept in memory. There is a service to retrieve all
>>>>>>> metrics.
>>>>>>> There is also a Web Tools page to view all metrics.
>>>>>>>
>>>>>>> A heartbeat server could retrieve the metrics to check on server load
>>>>>>> or
>>>>>>> to provide histograms.
>>>>>>>
>>>>>>> The metric element has an optional threshold attribute, so some
>>>>>>> action
>>>>>>> could be taken when the metric crosses a threshold. For example, in
>>>>>>> the
>>>>>>> following request map:
>>>>>>>
>>>>>>> <request-map uri="ViewMetrics">
>>>>>>> <security https="true" auth="true"/>
>>>>>>> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>>>>>> <response name="success" type="view" value="ViewMetrics"/>
>>>>>>> <response name="threshold-exceeded" type="view"
>>>>>>> value="ServerBusy"/><!--
>>>>>>> displays a friendly 'server busy' page -->
>>>>>>> </request-map>
>>>>>>>
>>>>>>> the ServerBusy view would be rendered if the average response time
>>>>>>> exceeded 1000 mS. This can be useful for providing a lively web
>>>>>>> experience on a heavy-traffic web page.
>>>>>>>
>>>>>>> The service dispatcher does not use the threshold. I could not think
>>>>>>> of
>>>>>>> a use case where service behavior should be modified based on average
>>>>>>> execution time.
>>>>>>>
>>>>>>> The metrics code is very small - two java files. Also, the
>>>>>>> modifications
>>>>>>> to the webapp component and service component are very small.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>
>

Re: Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

Pierre,

Please stop wasting everyone's time. We have tried to explain to you how 
the community works. If it is that difficult for you to grasp, then 
perhaps you should just let it go.

-Adrian

On 7/16/2012 1:02 PM, Pierre Smits wrote:
> There you have it. This commit should and must be reverted because Apache
> procedures weren't followed. I just reminded you of that.
>
> When you asked for the opinions of the community you solicited a vote. Thus
> procedures should be followed. Or do you feel that you can implement
> changes without following procedures?
>
>
> 2012/7/16 Jacques Le Roux <ja...@les7arts.com>
>
>> As we already agreed long ago, the flow should roughly be:
>> Dev ML proposition  => dev ML dicusssion => if tiny change and community
>> consensus then code and commit else if not tiny change (I let apart no
>> consensys as it's obvious) => Jira + patch => reviews (not only from
>> committers, we pray developers not being committers to review as well, a
>> good way to become committers BTW) => if agreement then commit => if
>> necessary and possible create a wiki page to explain the feature
>>
>> Did I miss something? Ha maybe vote. In a rare cases where there is no
>> consensus (as a community we should always try to get to a consensus) and
>> the community thinks a vote is needed.
>>
>> Please refer to ASF documentation for more http://www.apache.org/**
>> foundation/voting.html <http://www.apache.org/foundation/voting.html>
>>
>> So the preliminary doc (mostly requirements, etc) should be in Jira, then
>> completed in wiki
>>
>> David also created a wiki space for "OFBiz Requirements and Designs":
>> https://cwiki.apache.org/**confluence/display/OFBREQDES/**Home<https://cwiki.apache.org/confluence/display/OFBREQDES/Home>.
>> This could be used in BJ's spirit for larger tasks...
>>
>> Jacques
>>
>> From: "BJ Freeman" <bj...@free-man.net>
>>
>>   that is true, however a month from now it will be lost and will have to
>>> be searched.
>>> So you start by putting you proposal on the wiki then link in the email
>>> for discussion.
>>> once the discussion is completed it is put on the wiki with a link to a
>>> page of the discussion. and a synopsis of the result of the discussion.
>>>
>>> Adrian Crum sent the following on 7/16/2012 3:45 AM:
>>>
>>>> Having a Wiki page that describes the new feature would be great, but it
>>>> needs to be created after the commit and some review. Creating a Wiki
>>>> page before there is any interest expressed in the proposal could be a
>>>> waste of time. So, I cover the goal, scope, and effect on the current
>>>> design in the emailed proposal.
>>>>
>>>> -Adrian
>>>>
>>>> On 7/16/2012 11:32 AM, BJ Freeman wrote:
>>>>
>>>>> What would be great is if we had a Dev map that showed a design plan
>>>>> The Goal, Scope, and effect on the current design.
>>>>> having all these in one place on the wiki would help in over all design.
>>>>> my 2 cents.
>>>>>
>>>>> Adrian Crum sent the following on 7/14/2012 3:38 AM:
>>>>>
>>>>>> I have an application metrics feature working on my local copy and I
>>>>>> was
>>>>>> wondering if there would be any interest in including it in the
>>>>>> project.
>>>>>>
>>>>>> A metric is a measure of average execution time. Each metric is given a
>>>>>> unique name.
>>>>>>
>>>>>> I modified the control servlet and service dispatcher to use metrics.
>>>>>> To
>>>>>> add a metric to a request, just include an XML element:
>>>>>>
>>>>>> <metric name="URL: webtools/main" />
>>>>>>
>>>>>> to the request map and the average response time for the URL will be
>>>>>> maintained. Likewise, to add a metric to a service, just include an XML
>>>>>> element:
>>>>>>
>>>>>> <metric name="Service: createMaintsFromTimeInterval" />
>>>>>>
>>>>>> to the service definition and the average execution time for the
>>>>>> service
>>>>>> will be maintained.
>>>>>>
>>>>>> Metrics are kept in memory. There is a service to retrieve all metrics.
>>>>>> There is also a Web Tools page to view all metrics.
>>>>>>
>>>>>> A heartbeat server could retrieve the metrics to check on server load
>>>>>> or
>>>>>> to provide histograms.
>>>>>>
>>>>>> The metric element has an optional threshold attribute, so some action
>>>>>> could be taken when the metric crosses a threshold. For example, in the
>>>>>> following request map:
>>>>>>
>>>>>> <request-map uri="ViewMetrics">
>>>>>> <security https="true" auth="true"/>
>>>>>> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>>>>> <response name="success" type="view" value="ViewMetrics"/>
>>>>>> <response name="threshold-exceeded" type="view"
>>>>>> value="ServerBusy"/><!--
>>>>>> displays a friendly 'server busy' page -->
>>>>>> </request-map>
>>>>>>
>>>>>> the ServerBusy view would be rendered if the average response time
>>>>>> exceeded 1000 mS. This can be useful for providing a lively web
>>>>>> experience on a heavy-traffic web page.
>>>>>>
>>>>>> The service dispatcher does not use the threshold. I could not think of
>>>>>> a use case where service behavior should be modified based on average
>>>>>> execution time.
>>>>>>
>>>>>> The metrics code is very small - two java files. Also, the
>>>>>> modifications
>>>>>> to the webapp component and service component are very small.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>

Re: Discussion: Application Metrics Feature

[Jacques Le Roux <ja...@les7arts.com>]

Pierre,

The below procedure are not ASF but OFBiz. There is nothing about it in ASF rules. Each community is asked to use its own. These are 
OFBiz's.
Please note that only PMC members have the right to vetoing a commit http://www.apache.org/foundation/voting.html#binding-votes
also read carefully http://www.apache.org/foundation/voting.html#Veto and all the page

It's all about meritocracy http://www.apache.org/foundation/how-it-works.html#meritocracy

Jacques

From: "Pierre Smits" <pi...@gmail.com>
> There you have it. This commit should and must be reverted because Apache
> procedures weren't followed. I just reminded you of that.
>
> When you asked for the opinions of the community you solicited a vote. Thus
> procedures should be followed. Or do you feel that you can implement
> changes without following procedures?
>
>
> 2012/7/16 Jacques Le Roux <ja...@les7arts.com>
>
>> As we already agreed long ago, the flow should roughly be:
>> Dev ML proposition  => dev ML dicusssion => if tiny change and community
>> consensus then code and commit else if not tiny change (I let apart no
>> consensys as it's obvious) => Jira + patch => reviews (not only from
>> committers, we pray developers not being committers to review as well, a
>> good way to become committers BTW) => if agreement then commit => if
>> necessary and possible create a wiki page to explain the feature
>>
>> Did I miss something? Ha maybe vote. In a rare cases where there is no
>> consensus (as a community we should always try to get to a consensus) and
>> the community thinks a vote is needed.
>>
>> Please refer to ASF documentation for more http://www.apache.org/**
>> foundation/voting.html <http://www.apache.org/foundation/voting.html>
>>
>> So the preliminary doc (mostly requirements, etc) should be in Jira, then
>> completed in wiki
>>
>> David also created a wiki space for "OFBiz Requirements and Designs":
>> https://cwiki.apache.org/**confluence/display/OFBREQDES/**Home<https://cwiki.apache.org/confluence/display/OFBREQDES/Home>.
>> This could be used in BJ's spirit for larger tasks...
>>
>> Jacques
>>
>> From: "BJ Freeman" <bj...@free-man.net>
>>
>>  that is true, however a month from now it will be lost and will have to
>>> be searched.
>>> So you start by putting you proposal on the wiki then link in the email
>>> for discussion.
>>> once the discussion is completed it is put on the wiki with a link to a
>>> page of the discussion. and a synopsis of the result of the discussion.
>>>
>>> Adrian Crum sent the following on 7/16/2012 3:45 AM:
>>>
>>>> Having a Wiki page that describes the new feature would be great, but it
>>>> needs to be created after the commit and some review. Creating a Wiki
>>>> page before there is any interest expressed in the proposal could be a
>>>> waste of time. So, I cover the goal, scope, and effect on the current
>>>> design in the emailed proposal.
>>>>
>>>> -Adrian
>>>>
>>>> On 7/16/2012 11:32 AM, BJ Freeman wrote:
>>>>
>>>>> What would be great is if we had a Dev map that showed a design plan
>>>>> The Goal, Scope, and effect on the current design.
>>>>> having all these in one place on the wiki would help in over all design.
>>>>> my 2 cents.
>>>>>
>>>>> Adrian Crum sent the following on 7/14/2012 3:38 AM:
>>>>>
>>>>>> I have an application metrics feature working on my local copy and I
>>>>>> was
>>>>>> wondering if there would be any interest in including it in the
>>>>>> project.
>>>>>>
>>>>>> A metric is a measure of average execution time. Each metric is given a
>>>>>> unique name.
>>>>>>
>>>>>> I modified the control servlet and service dispatcher to use metrics.
>>>>>> To
>>>>>> add a metric to a request, just include an XML element:
>>>>>>
>>>>>> <metric name="URL: webtools/main" />
>>>>>>
>>>>>> to the request map and the average response time for the URL will be
>>>>>> maintained. Likewise, to add a metric to a service, just include an XML
>>>>>> element:
>>>>>>
>>>>>> <metric name="Service: createMaintsFromTimeInterval" />
>>>>>>
>>>>>> to the service definition and the average execution time for the
>>>>>> service
>>>>>> will be maintained.
>>>>>>
>>>>>> Metrics are kept in memory. There is a service to retrieve all metrics.
>>>>>> There is also a Web Tools page to view all metrics.
>>>>>>
>>>>>> A heartbeat server could retrieve the metrics to check on server load
>>>>>> or
>>>>>> to provide histograms.
>>>>>>
>>>>>> The metric element has an optional threshold attribute, so some action
>>>>>> could be taken when the metric crosses a threshold. For example, in the
>>>>>> following request map:
>>>>>>
>>>>>> <request-map uri="ViewMetrics">
>>>>>> <security https="true" auth="true"/>
>>>>>> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>>>>> <response name="success" type="view" value="ViewMetrics"/>
>>>>>> <response name="threshold-exceeded" type="view"
>>>>>> value="ServerBusy"/><!--
>>>>>> displays a friendly 'server busy' page -->
>>>>>> </request-map>
>>>>>>
>>>>>> the ServerBusy view would be rendered if the average response time
>>>>>> exceeded 1000 mS. This can be useful for providing a lively web
>>>>>> experience on a heavy-traffic web page.
>>>>>>
>>>>>> The service dispatcher does not use the threshold. I could not think of
>>>>>> a use case where service behavior should be modified based on average
>>>>>> execution time.
>>>>>>
>>>>>> The metrics code is very small - two java files. Also, the
>>>>>> modifications
>>>>>> to the webapp component and service component are very small.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
> 

Re: Discussion: Application Metrics Feature

[Pierre Smits <pi...@gmail.com>]

There you have it. This commit should and must be reverted because Apache
procedures weren't followed. I just reminded you of that.

When you asked for the opinions of the community you solicited a vote. Thus
procedures should be followed. Or do you feel that you can implement
changes without following procedures?


2012/7/16 Jacques Le Roux <ja...@les7arts.com>

> As we already agreed long ago, the flow should roughly be:
> Dev ML proposition  => dev ML dicusssion => if tiny change and community
> consensus then code and commit else if not tiny change (I let apart no
> consensys as it's obvious) => Jira + patch => reviews (not only from
> committers, we pray developers not being committers to review as well, a
> good way to become committers BTW) => if agreement then commit => if
> necessary and possible create a wiki page to explain the feature
>
> Did I miss something? Ha maybe vote. In a rare cases where there is no
> consensus (as a community we should always try to get to a consensus) and
> the community thinks a vote is needed.
>
> Please refer to ASF documentation for more http://www.apache.org/**
> foundation/voting.html <http://www.apache.org/foundation/voting.html>
>
> So the preliminary doc (mostly requirements, etc) should be in Jira, then
> completed in wiki
>
> David also created a wiki space for "OFBiz Requirements and Designs":
> https://cwiki.apache.org/**confluence/display/OFBREQDES/**Home<https://cwiki.apache.org/confluence/display/OFBREQDES/Home>.
> This could be used in BJ's spirit for larger tasks...
>
> Jacques
>
> From: "BJ Freeman" <bj...@free-man.net>
>
>  that is true, however a month from now it will be lost and will have to
>> be searched.
>> So you start by putting you proposal on the wiki then link in the email
>> for discussion.
>> once the discussion is completed it is put on the wiki with a link to a
>> page of the discussion. and a synopsis of the result of the discussion.
>>
>> Adrian Crum sent the following on 7/16/2012 3:45 AM:
>>
>>> Having a Wiki page that describes the new feature would be great, but it
>>> needs to be created after the commit and some review. Creating a Wiki
>>> page before there is any interest expressed in the proposal could be a
>>> waste of time. So, I cover the goal, scope, and effect on the current
>>> design in the emailed proposal.
>>>
>>> -Adrian
>>>
>>> On 7/16/2012 11:32 AM, BJ Freeman wrote:
>>>
>>>> What would be great is if we had a Dev map that showed a design plan
>>>> The Goal, Scope, and effect on the current design.
>>>> having all these in one place on the wiki would help in over all design.
>>>> my 2 cents.
>>>>
>>>> Adrian Crum sent the following on 7/14/2012 3:38 AM:
>>>>
>>>>> I have an application metrics feature working on my local copy and I
>>>>> was
>>>>> wondering if there would be any interest in including it in the
>>>>> project.
>>>>>
>>>>> A metric is a measure of average execution time. Each metric is given a
>>>>> unique name.
>>>>>
>>>>> I modified the control servlet and service dispatcher to use metrics.
>>>>> To
>>>>> add a metric to a request, just include an XML element:
>>>>>
>>>>> <metric name="URL: webtools/main" />
>>>>>
>>>>> to the request map and the average response time for the URL will be
>>>>> maintained. Likewise, to add a metric to a service, just include an XML
>>>>> element:
>>>>>
>>>>> <metric name="Service: createMaintsFromTimeInterval" />
>>>>>
>>>>> to the service definition and the average execution time for the
>>>>> service
>>>>> will be maintained.
>>>>>
>>>>> Metrics are kept in memory. There is a service to retrieve all metrics.
>>>>> There is also a Web Tools page to view all metrics.
>>>>>
>>>>> A heartbeat server could retrieve the metrics to check on server load
>>>>> or
>>>>> to provide histograms.
>>>>>
>>>>> The metric element has an optional threshold attribute, so some action
>>>>> could be taken when the metric crosses a threshold. For example, in the
>>>>> following request map:
>>>>>
>>>>> <request-map uri="ViewMetrics">
>>>>> <security https="true" auth="true"/>
>>>>> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>>>> <response name="success" type="view" value="ViewMetrics"/>
>>>>> <response name="threshold-exceeded" type="view"
>>>>> value="ServerBusy"/><!--
>>>>> displays a friendly 'server busy' page -->
>>>>> </request-map>
>>>>>
>>>>> the ServerBusy view would be rendered if the average response time
>>>>> exceeded 1000 mS. This can be useful for providing a lively web
>>>>> experience on a heavy-traffic web page.
>>>>>
>>>>> The service dispatcher does not use the threshold. I could not think of
>>>>> a use case where service behavior should be modified based on average
>>>>> execution time.
>>>>>
>>>>> The metrics code is very small - two java files. Also, the
>>>>> modifications
>>>>> to the webapp component and service component are very small.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>

Re: Discussion: Application Metrics Feature

[Jacques Le Roux <ja...@les7arts.com>]

As we already agreed long ago, the flow should roughly be:
Dev ML proposition  => dev ML dicusssion => if tiny change and community consensus then code and commit else if not tiny change (I 
let apart no consensys as it's obvious) => Jira + patch => reviews (not only from committers, we pray developers not being 
committers to review as well, a good way to become committers BTW) => if agreement then commit => if necessary and possible create a 
wiki page to explain the feature

Did I miss something? Ha maybe vote. In a rare cases where there is no consensus (as a community we should always try to get to a 
consensus) and the community thinks a vote is needed.

Please refer to ASF documentation for more http://www.apache.org/foundation/voting.html

So the preliminary doc (mostly requirements, etc) should be in Jira, then completed in wiki

David also created a wiki space for "OFBiz Requirements and Designs": https://cwiki.apache.org/confluence/display/OFBREQDES/Home. 
This could be used in BJ's spirit for larger tasks...

Jacques

From: "BJ Freeman" <bj...@free-man.net>
> that is true, however a month from now it will be lost and will have to be searched.
> So you start by putting you proposal on the wiki then link in the email for discussion.
> once the discussion is completed it is put on the wiki with a link to a page of the discussion. and a synopsis of the result of 
> the discussion.
>
> Adrian Crum sent the following on 7/16/2012 3:45 AM:
>> Having a Wiki page that describes the new feature would be great, but it
>> needs to be created after the commit and some review. Creating a Wiki
>> page before there is any interest expressed in the proposal could be a
>> waste of time. So, I cover the goal, scope, and effect on the current
>> design in the emailed proposal.
>>
>> -Adrian
>>
>> On 7/16/2012 11:32 AM, BJ Freeman wrote:
>>> What would be great is if we had a Dev map that showed a design plan
>>> The Goal, Scope, and effect on the current design.
>>> having all these in one place on the wiki would help in over all design.
>>> my 2 cents.
>>>
>>> Adrian Crum sent the following on 7/14/2012 3:38 AM:
>>>> I have an application metrics feature working on my local copy and I was
>>>> wondering if there would be any interest in including it in the project.
>>>>
>>>> A metric is a measure of average execution time. Each metric is given a
>>>> unique name.
>>>>
>>>> I modified the control servlet and service dispatcher to use metrics. To
>>>> add a metric to a request, just include an XML element:
>>>>
>>>> <metric name="URL: webtools/main" />
>>>>
>>>> to the request map and the average response time for the URL will be
>>>> maintained. Likewise, to add a metric to a service, just include an XML
>>>> element:
>>>>
>>>> <metric name="Service: createMaintsFromTimeInterval" />
>>>>
>>>> to the service definition and the average execution time for the service
>>>> will be maintained.
>>>>
>>>> Metrics are kept in memory. There is a service to retrieve all metrics.
>>>> There is also a Web Tools page to view all metrics.
>>>>
>>>> A heartbeat server could retrieve the metrics to check on server load or
>>>> to provide histograms.
>>>>
>>>> The metric element has an optional threshold attribute, so some action
>>>> could be taken when the metric crosses a threshold. For example, in the
>>>> following request map:
>>>>
>>>> <request-map uri="ViewMetrics">
>>>> <security https="true" auth="true"/>
>>>> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>>> <response name="success" type="view" value="ViewMetrics"/>
>>>> <response name="threshold-exceeded" type="view" value="ServerBusy"/><!--
>>>> displays a friendly 'server busy' page -->
>>>> </request-map>
>>>>
>>>> the ServerBusy view would be rendered if the average response time
>>>> exceeded 1000 mS. This can be useful for providing a lively web
>>>> experience on a heavy-traffic web page.
>>>>
>>>> The service dispatcher does not use the threshold. I could not think of
>>>> a use case where service behavior should be modified based on average
>>>> execution time.
>>>>
>>>> The metrics code is very small - two java files. Also, the modifications
>>>> to the webapp component and service component are very small.
>>>>
>>>> What do you think?
>>>>
>>>> -Adrian
>>>>
>>>>
>>
>>
>> 

Re: Discussion: Application Metrics Feature

[BJ Freeman <bj...@free-man.net>]

that is true, however a month from now it will be lost and will have to 
be searched.
So you start by putting you proposal on the wiki then link in the email 
for discussion.
once the discussion is completed it is put on the wiki with a link to a 
page of the discussion. and a synopsis of the result of the discussion.

Adrian Crum sent the following on 7/16/2012 3:45 AM:
> Having a Wiki page that describes the new feature would be great, but it
> needs to be created after the commit and some review. Creating a Wiki
> page before there is any interest expressed in the proposal could be a
> waste of time. So, I cover the goal, scope, and effect on the current
> design in the emailed proposal.
>
> -Adrian
>
> On 7/16/2012 11:32 AM, BJ Freeman wrote:
>> What would be great is if we had a Dev map that showed a design plan
>> The Goal, Scope, and effect on the current design.
>> having all these in one place on the wiki would help in over all design.
>> my 2 cents.
>>
>> Adrian Crum sent the following on 7/14/2012 3:38 AM:
>>> I have an application metrics feature working on my local copy and I was
>>> wondering if there would be any interest in including it in the project.
>>>
>>> A metric is a measure of average execution time. Each metric is given a
>>> unique name.
>>>
>>> I modified the control servlet and service dispatcher to use metrics. To
>>> add a metric to a request, just include an XML element:
>>>
>>> <metric name="URL: webtools/main" />
>>>
>>> to the request map and the average response time for the URL will be
>>> maintained. Likewise, to add a metric to a service, just include an XML
>>> element:
>>>
>>> <metric name="Service: createMaintsFromTimeInterval" />
>>>
>>> to the service definition and the average execution time for the service
>>> will be maintained.
>>>
>>> Metrics are kept in memory. There is a service to retrieve all metrics.
>>> There is also a Web Tools page to view all metrics.
>>>
>>> A heartbeat server could retrieve the metrics to check on server load or
>>> to provide histograms.
>>>
>>> The metric element has an optional threshold attribute, so some action
>>> could be taken when the metric crosses a threshold. For example, in the
>>> following request map:
>>>
>>> <request-map uri="ViewMetrics">
>>> <security https="true" auth="true"/>
>>> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>> <response name="success" type="view" value="ViewMetrics"/>
>>> <response name="threshold-exceeded" type="view" value="ServerBusy"/><!--
>>> displays a friendly 'server busy' page -->
>>> </request-map>
>>>
>>> the ServerBusy view would be rendered if the average response time
>>> exceeded 1000 mS. This can be useful for providing a lively web
>>> experience on a heavy-traffic web page.
>>>
>>> The service dispatcher does not use the threshold. I could not think of
>>> a use case where service behavior should be modified based on average
>>> execution time.
>>>
>>> The metrics code is very small - two java files. Also, the modifications
>>> to the webapp component and service component are very small.
>>>
>>> What do you think?
>>>
>>> -Adrian
>>>
>>>
>
>
>

Re: Discussion: Application Metrics Feature

[Adrian Crum <ad...@sandglass-software.com>]

Having a Wiki page that describes the new feature would be great, but it 
needs to be created after the commit and some review. Creating a Wiki 
page before there is any interest expressed in the proposal could be a 
waste of time. So, I cover the goal, scope, and effect on the current 
design in the emailed proposal.

-Adrian

On 7/16/2012 11:32 AM, BJ Freeman wrote:
> What would be great is if we had a Dev map that showed a design plan
> The Goal, Scope, and effect on the current design.
> having all these in one place on the wiki would help in over all design.
> my 2 cents.
>
> Adrian Crum sent the following on 7/14/2012 3:38 AM:
>> I have an application metrics feature working on my local copy and I was
>> wondering if there would be any interest in including it in the project.
>>
>> A metric is a measure of average execution time. Each metric is given a
>> unique name.
>>
>> I modified the control servlet and service dispatcher to use metrics. To
>> add a metric to a request, just include an XML element:
>>
>> <metric name="URL: webtools/main" />
>>
>> to the request map and the average response time for the URL will be
>> maintained. Likewise, to add a metric to a service, just include an XML
>> element:
>>
>> <metric name="Service: createMaintsFromTimeInterval" />
>>
>> to the service definition and the average execution time for the service
>> will be maintained.
>>
>> Metrics are kept in memory. There is a service to retrieve all metrics.
>> There is also a Web Tools page to view all metrics.
>>
>> A heartbeat server could retrieve the metrics to check on server load or
>> to provide histograms.
>>
>> The metric element has an optional threshold attribute, so some action
>> could be taken when the metric crosses a threshold. For example, in the
>> following request map:
>>
>> <request-map uri="ViewMetrics">
>> <security https="true" auth="true"/>
>> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>> <response name="success" type="view" value="ViewMetrics"/>
>> <response name="threshold-exceeded" type="view" value="ServerBusy"/><!--
>> displays a friendly 'server busy' page -->
>> </request-map>
>>
>> the ServerBusy view would be rendered if the average response time
>> exceeded 1000 mS. This can be useful for providing a lively web
>> experience on a heavy-traffic web page.
>>
>> The service dispatcher does not use the threshold. I could not think of
>> a use case where service behavior should be modified based on average
>> execution time.
>>
>> The metrics code is very small - two java files. Also, the modifications
>> to the webapp component and service component are very small.
>>
>> What do you think?
>>
>> -Adrian
>>
>>

Re: Discussion: Application Metrics Feature

[BJ Freeman <bj...@free-man.net>]

What would be great is if we had a Dev map that showed a design plan
The Goal, Scope, and effect on the current design.
having all these in one place on the wiki would help in over all design.
my 2 cents.

Adrian Crum sent the following on 7/14/2012 3:38 AM:
> I have an application metrics feature working on my local copy and I was
> wondering if there would be any interest in including it in the project.
>
> A metric is a measure of average execution time. Each metric is given a
> unique name.
>
> I modified the control servlet and service dispatcher to use metrics. To
> add a metric to a request, just include an XML element:
>
> <metric name="URL: webtools/main" />
>
> to the request map and the average response time for the URL will be
> maintained. Likewise, to add a metric to a service, just include an XML
> element:
>
> <metric name="Service: createMaintsFromTimeInterval" />
>
> to the service definition and the average execution time for the service
> will be maintained.
>
> Metrics are kept in memory. There is a service to retrieve all metrics.
> There is also a Web Tools page to view all metrics.
>
> A heartbeat server could retrieve the metrics to check on server load or
> to provide histograms.
>
> The metric element has an optional threshold attribute, so some action
> could be taken when the metric crosses a threshold. For example, in the
> following request map:
>
> <request-map uri="ViewMetrics">
> <security https="true" auth="true"/>
> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
> <response name="success" type="view" value="ViewMetrics"/>
> <response name="threshold-exceeded" type="view" value="ServerBusy"/><!--
> displays a friendly 'server busy' page -->
> </request-map>
>
> the ServerBusy view would be rendered if the average response time
> exceeded 1000 mS. This can be useful for providing a lively web
> experience on a heavy-traffic web page.
>
> The service dispatcher does not use the threshold. I could not think of
> a use case where service behavior should be modified based on average
> execution time.
>
> The metrics code is very small - two java files. Also, the modifications
> to the webapp component and service component are very small.
>
> What do you think?
>
> -Adrian
>
>