On Wed, Aug 5, 2009 at 11:12 PM, Reinhard Pötz<[email protected]> wrote: > Dariusz Łuksza wrote: >> On Mon, Jul 27, 2009 at 4:18 PM, Reinhard Pötz<[email protected]> wrote: >>> Dariusz Łuksza wrote: >>>> 2009/7/24 Dariusz Łuksza <[email protected]>: >>>>>> Thanks for that tip I'll look on this ASAP ;) >>>>>> >>>>> For our needs every pipeline should have an id parameter, from one >>>>> hand it is very good solution because we get simple way how to divide >>>>> and present cache entry's on JMX and on the other hand I'm not quite >>>>> sure that we can require that parameter for every pipeline and user even >>>>> if he >>>>> don't use monitoring module >>>>> >>>>> What do you think ? >>>>> >>>> There is also third solution ... pipeline id parameter can be optional >>>> and we'll publish on JMX _only_ that cache entry's that belongs to >>>> pipeline that have set id parameter. This approach gives us additional >>>> configuration options and can reduce amount of data published on JMX. >>>> IMHO this is the best solution right now. >>> +1 >>> >> >> And here it is: >> https://issues.apache.org/jira/secure/attachment/12414657/cache-overview-part3-cache-entrys.patch >> >> What operation (besides: getValue() and getSize()), would be useful >> for every cache entry ? > > Everything works great, thanks! > > There is one thing that I would like to see changed: You set the > jmx-group-name in the cache key. I would prefer if this would do the > pipeline itself instead because imo jmx is not the cache key's concern. > The second reason is that your implementation only works by accident > because you can access the <pipeline> parameters (in this case > 'jmx-group-name') in components which is a bug IMO. > > Instead you can override the setConfiguration() Method in the > CachingPipeline in order to get access to its parameters and use the > value in setCachedValue().
OK, I'll change it ASAP. > - o - > > I know that it's not part of your GSoC project, but if time permits now > or after it, it would be great to get some basic integration tests that > check if the JMX beans are exposed. This will make ensure that the > functionality doesn't get broken fundamentally. > I think that I'll continue working on this project after GSoC so integration tests (and other improvements) would be implemented in near future ;) -- Best regards Blog: http://luksza.org LinkedIn: http://www.linkedin.com/in/dariuszluksza
