You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2021/10/19 12:36:48 UTC
Marker design issue
Hi All,
I get bit by this every time I try to make my markers "fancy" so I took the
time this go around to open up a discussion :-)
I want markers:
Bob.children.John
Bob.children.Jimmy
Alice.children.Rose
Alice.children.Sue
(Never mind Alice.chidren.Bob)
I want to turn off only "Bob.children" but I can't because "children" is
effectively global and either can be defined in code with:
Only Bob as it's parent,
Only Alice as it's parent,
Both Bob and Alice as parents (uh...?)
This is a complete mismatch with hierarchical naming with have with Loggers
and confusing to no end, and not documented.
Can/should we "fix" markers to behave like a clean hierarchy?
Or, should hierarchical marker names be provided in some different way?
With a different character than a dot for example?
I was about to write some docs internal to a product at work to show how to
get logging to perform these fancy tricks but I won't until I get a
clearer picture of what we can/should do for this type of use case.
TY!
Gary
Re: Marker design issue
Posted by Gary Gregory <ga...@gmail.com>.
Ah, no, I won't do that as the example code below only uses deprecated
methods. I'll keep using setParents(Marker).
Gary
On Tue, Oct 19, 2021, 12:57 Gary Gregory <ga...@gmail.com> wrote:
> Thanks for getting back to me Ralph. I'll try the API pattern you provided.
>
> Gary
>
>
> On Tue, Oct 19, 2021, 11:33 Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> You are free to put dots in marker names, or any other character for that
>> matter.
>>
>> Markers are created with MarkerManager. Every marker has a unique name
>> and can
>> only have one parent. So the way you have expressed the problem below is
>> really incorrect.
>>
>> I really don’t like your example as most people would leave a node named
>> “children” out
>> because it is redundant. Being a child is an object relationship. So
>> “Children” is a
>> child of Bob in your example and John and Jimmy are children of
>> “Children”.
>>
>> What you really have looks something like:
>>
>> Pet
>> ↑
>> Mammal
>> ↑ ↑
>> Cat Dog
>>
>> To create this you have to do:
>> Marker pet = MarkerManager.createMarker(“Pet”);
>> Marker mammal = MarkerManager.createMarker(“Mammal” ,pets);
>> Marker cat = MarkerManager.createMarker(“Cat”, mammal);
>> Marker dog = MarkerManger.createMarker(“Dog”, mammal);
>>
>> The equivalent problem is that we now want a parent named “Wild
>> Animals”. Of course
>> it could also have mammals. But to do that you would need to have the
>> marker be named
>> something like “Wild Mammals”.
>>
>> That is just the way it is because in your configuration you do not
>> specify “Pet.Mammal.Cat”
>> as the marker name. You only specify “Cat”. Or you can specify “Pet” in
>> the configuration
>> and it will match any event using the “Mammal”, “Cat”, or “Dog” marker.
>>
>> The reason a Marker can only have a single parent is strictly due to
>> performance. Walking
>> the parent markers to see if there is a match is not particularly fast.
>> Having to traverse
>> multiple parent hierarchies would make it even slower. As it is, I
>> suspect Markers aren’t
>> used that heavily so trying to make it even fancier seems like overkill.
>>
>> Ralph
>>
>>
>> > On Oct 19, 2021, at 6:55 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> >
>> > Hi All,
>> >
>> > I get bit by this every time I try to make my markers "fancy" so I took
>> the
>> > time this go around to open up a discussion :-)
>> >
>> > I want markers:
>> >
>> > Bob.children.John
>> > Bob.children.Jimmy
>> > Alice.children.Rose
>> > Alice.children.Sue
>> > (Never mind Alice.chidren.Bob)
>> >
>> > I want to turn off only "Bob.children" but I can't because "children" is
>> > effectively global and either can be defined in code with:
>> > Only Bob as it's parent,
>> > Only Alice as it's parent,
>> > Both Bob and Alice as parents (uh...?)
>> >
>> > This is a complete mismatch with hierarchical naming with have with
>> Loggers
>> > and confusing to no end, and not documented.
>> >
>> > Can/should we "fix" markers to behave like a clean hierarchy?
>> >
>> > Or, should hierarchical marker names be provided in some different way?
>> > With a different character than a dot for example?
>> >
>> > I was about to write some docs internal to a product at work to show
>> how to
>> > get logging to perform these fancy tricks but I won't until I get a
>> > clearer picture of what we can/should do for this type of use case.
>> >
>> > TY!
>> > Gary
>>
>>
>>
Re: Marker design issue
Posted by Gary Gregory <ga...@gmail.com>.
Thanks for getting back to me Ralph. I'll try the API pattern you provided.
Gary
On Tue, Oct 19, 2021, 11:33 Ralph Goers <ra...@dslextreme.com> wrote:
> You are free to put dots in marker names, or any other character for that
> matter.
>
> Markers are created with MarkerManager. Every marker has a unique name and
> can
> only have one parent. So the way you have expressed the problem below is
> really incorrect.
>
> I really don’t like your example as most people would leave a node named
> “children” out
> because it is redundant. Being a child is an object relationship. So
> “Children” is a
> child of Bob in your example and John and Jimmy are children of “Children”.
>
> What you really have looks something like:
>
> Pet
> ↑
> Mammal
> ↑ ↑
> Cat Dog
>
> To create this you have to do:
> Marker pet = MarkerManager.createMarker(“Pet”);
> Marker mammal = MarkerManager.createMarker(“Mammal” ,pets);
> Marker cat = MarkerManager.createMarker(“Cat”, mammal);
> Marker dog = MarkerManger.createMarker(“Dog”, mammal);
>
> The equivalent problem is that we now want a parent named “Wild Animals”.
> Of course
> it could also have mammals. But to do that you would need to have the
> marker be named
> something like “Wild Mammals”.
>
> That is just the way it is because in your configuration you do not
> specify “Pet.Mammal.Cat”
> as the marker name. You only specify “Cat”. Or you can specify “Pet” in
> the configuration
> and it will match any event using the “Mammal”, “Cat”, or “Dog” marker.
>
> The reason a Marker can only have a single parent is strictly due to
> performance. Walking
> the parent markers to see if there is a match is not particularly fast.
> Having to traverse
> multiple parent hierarchies would make it even slower. As it is, I suspect
> Markers aren’t
> used that heavily so trying to make it even fancier seems like overkill.
>
> Ralph
>
>
> > On Oct 19, 2021, at 6:55 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > Hi All,
> >
> > I get bit by this every time I try to make my markers "fancy" so I took
> the
> > time this go around to open up a discussion :-)
> >
> > I want markers:
> >
> > Bob.children.John
> > Bob.children.Jimmy
> > Alice.children.Rose
> > Alice.children.Sue
> > (Never mind Alice.chidren.Bob)
> >
> > I want to turn off only "Bob.children" but I can't because "children" is
> > effectively global and either can be defined in code with:
> > Only Bob as it's parent,
> > Only Alice as it's parent,
> > Both Bob and Alice as parents (uh...?)
> >
> > This is a complete mismatch with hierarchical naming with have with
> Loggers
> > and confusing to no end, and not documented.
> >
> > Can/should we "fix" markers to behave like a clean hierarchy?
> >
> > Or, should hierarchical marker names be provided in some different way?
> > With a different character than a dot for example?
> >
> > I was about to write some docs internal to a product at work to show how
> to
> > get logging to perform these fancy tricks but I won't until I get a
> > clearer picture of what we can/should do for this type of use case.
> >
> > TY!
> > Gary
>
>
>
Re: Marker design issue
Posted by Ralph Goers <ra...@dslextreme.com>.
You are free to put dots in marker names, or any other character for that matter.
Markers are created with MarkerManager. Every marker has a unique name and can
only have one parent. So the way you have expressed the problem below is really incorrect.
I really don’t like your example as most people would leave a node named “children” out
because it is redundant. Being a child is an object relationship. So “Children” is a
child of Bob in your example and John and Jimmy are children of “Children”.
What you really have looks something like:
Pet
↑
Mammal
↑ ↑
Cat Dog
To create this you have to do:
Marker pet = MarkerManager.createMarker(“Pet”);
Marker mammal = MarkerManager.createMarker(“Mammal” ,pets);
Marker cat = MarkerManager.createMarker(“Cat”, mammal);
Marker dog = MarkerManger.createMarker(“Dog”, mammal);
The equivalent problem is that we now want a parent named “Wild Animals”. Of course
it could also have mammals. But to do that you would need to have the marker be named
something like “Wild Mammals”.
That is just the way it is because in your configuration you do not specify “Pet.Mammal.Cat”
as the marker name. You only specify “Cat”. Or you can specify “Pet” in the configuration
and it will match any event using the “Mammal”, “Cat”, or “Dog” marker.
The reason a Marker can only have a single parent is strictly due to performance. Walking
the parent markers to see if there is a match is not particularly fast. Having to traverse
multiple parent hierarchies would make it even slower. As it is, I suspect Markers aren’t
used that heavily so trying to make it even fancier seems like overkill.
Ralph
> On Oct 19, 2021, at 6:55 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Hi All,
>
> I get bit by this every time I try to make my markers "fancy" so I took the
> time this go around to open up a discussion :-)
>
> I want markers:
>
> Bob.children.John
> Bob.children.Jimmy
> Alice.children.Rose
> Alice.children.Sue
> (Never mind Alice.chidren.Bob)
>
> I want to turn off only "Bob.children" but I can't because "children" is
> effectively global and either can be defined in code with:
> Only Bob as it's parent,
> Only Alice as it's parent,
> Both Bob and Alice as parents (uh...?)
>
> This is a complete mismatch with hierarchical naming with have with Loggers
> and confusing to no end, and not documented.
>
> Can/should we "fix" markers to behave like a clean hierarchy?
>
> Or, should hierarchical marker names be provided in some different way?
> With a different character than a dot for example?
>
> I was about to write some docs internal to a product at work to show how to
> get logging to perform these fancy tricks but I won't until I get a
> clearer picture of what we can/should do for this type of use case.
>
> TY!
> Gary
Marker design issue
Posted by Gary Gregory <ga...@gmail.com>.
Hi All,
I get bit by this every time I try to make my markers "fancy" so I took the
time this go around to open up a discussion :-)
I want markers:
Bob.children.John
Bob.children.Jimmy
Alice.children.Rose
Alice.children.Sue
(Never mind Alice.chidren.Bob)
I want to turn off only "Bob.children" but I can't because "children" is
effectively global and either can be defined in code with:
Only Bob as it's parent,
Only Alice as it's parent,
Both Bob and Alice as parents (uh...?)
This is a complete mismatch with hierarchical naming with have with Loggers
and confusing to no end, and not documented.
Can/should we "fix" markers to behave like a clean hierarchy?
Or, should hierarchical marker names be provided in some different way?
With a different character than a dot for example?
I was about to write some docs internal to a product at work to show how to
get logging to perform these fancy tricks but I won't until I get a
clearer picture of what we can/should do for this type of use case.
TY!
Gary
Re: Marker design issue
Posted by Gary Gregory <ga...@gmail.com>.
Oops...
On Tue, Oct 19, 2021, 09:29 sebb <se...@gmail.com> wrote:
> What commons component is involved here?
>
> On Tue, 19 Oct 2021 at 13:37, Gary Gregory <ga...@gmail.com> wrote:
> >
> > Hi All,
> >
> > I get bit by this every time I try to make my markers "fancy" so I took
> the
> > time this go around to open up a discussion :-)
> >
> > I want markers:
> >
> > Bob.children.John
> > Bob.children.Jimmy
> > Alice.children.Rose
> > Alice.children.Sue
> > (Never mind Alice.chidren.Bob)
> >
> > I want to turn off only "Bob.children" but I can't because "children" is
> > effectively global and either can be defined in code with:
> > Only Bob as it's parent,
> > Only Alice as it's parent,
> > Both Bob and Alice as parents (uh...?)
> >
> > This is a complete mismatch with hierarchical naming with have with
> Loggers
> > and confusing to no end, and not documented.
> >
> > Can/should we "fix" markers to behave like a clean hierarchy?
> >
> > Or, should hierarchical marker names be provided in some different way?
> > With a different character than a dot for example?
> >
> > I was about to write some docs internal to a product at work to show how
> to
> > get logging to perform these fancy tricks but I won't until I get a
> > clearer picture of what we can/should do for this type of use case.
> >
> > TY!
> > Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Marker design issue
Posted by sebb <se...@gmail.com>.
What commons component is involved here?
On Tue, 19 Oct 2021 at 13:37, Gary Gregory <ga...@gmail.com> wrote:
>
> Hi All,
>
> I get bit by this every time I try to make my markers "fancy" so I took the
> time this go around to open up a discussion :-)
>
> I want markers:
>
> Bob.children.John
> Bob.children.Jimmy
> Alice.children.Rose
> Alice.children.Sue
> (Never mind Alice.chidren.Bob)
>
> I want to turn off only "Bob.children" but I can't because "children" is
> effectively global and either can be defined in code with:
> Only Bob as it's parent,
> Only Alice as it's parent,
> Both Bob and Alice as parents (uh...?)
>
> This is a complete mismatch with hierarchical naming with have with Loggers
> and confusing to no end, and not documented.
>
> Can/should we "fix" markers to behave like a clean hierarchy?
>
> Or, should hierarchical marker names be provided in some different way?
> With a different character than a dot for example?
>
> I was about to write some docs internal to a product at work to show how to
> get logging to perform these fancy tricks but I won't until I get a
> clearer picture of what we can/should do for this type of use case.
>
> TY!
> Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org