gistfile1.txt

I propose to open another thread about Mark
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2013/10/23 Mark Struberg <struberg@yahoo.de>:


> This is the stuff we can use for applying the interceptors needed to gather the logging for EJB and CDI:
>
> https://github.com/struberg/InterDyn
>
> Wrote this 3 years ago and is used by quite some projects in the meantime.
>
> LieGrue,
> strub
>
>
>
>>________________________________
>> From: Romain Manni-Bucau <rmannibucau@gmail.com>
>>To: dev@sirona.incubator.apache.org
>>Sent: Wednesday, 23 October 2013, 17:32
>>Subject: Re: choices for 0.1-incubating?
>>
>>
>>Ok,
>>
>>* first: answer to the GUI:
>>1) I don't have anything against REST (there is already some rest
>>services btw) but not JAXRS (for conflicts). Just don't expect me to
>>do it in the following months ;). In short: +1 if that's not me who
>>needs to code it ;). I am OK if the velocity template served is just
>>the home page of the SPA. BTW keeping the ability for the user to
>>return a Template is great I think and ease the extension a lot.
>>
>>2) I don't agree on the fact the user doesn't have to update it.
>>Basically he doesn't need to work/update with existing plugins but
>>(and that's why Plugin API exists) he can do his own plugins and GUI.
>>We tested it @work and that's really great to see how easily it can be
>>extended with custom widgets. If you suppose JSon is enough you
>>mandate us to provides all needed widgets (so we wouldn't be a mini
>>framework anymore).
>>
>>no? Once against the proposal and what you say work together so maybe
>>just a word issue in my mail.
>>
>>* secondly: counter/gauge
>>
>>Yes gauges are close to metrics one. Basically just a timer collecting
>>(timestamp, value) 2-uples.
>>
>>About counters it is an aggregated view of values. It is backed by
>>SummarryStatistics of [math]. The interesting part is we don't need to
>>store the collection of values (and that's how our collector is able
>>to aggregate multiple instances counters). You have the stat info
>>listed here https://svn.apache.org/repos/asf/incubator/sirona/trunk/core/src/main/java/org/apache/sirona/counters/Counter.java
>>(min, max, stddev, sum, hits, ...)
>>
>>I still think SummarryStatistics impl could be optimized (ATM we need
>>a ReadWriteLock to make it consistent) but that's a great start.
>>
>>Hope I didn't forget anything
>>Romain Manni-Bucau
>>Twitter: @rmannibucau
>>Blog: http://rmannibucau.wordpress.com/
>>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>Github: https://github.com/rmannibucau
>>
>>
>>
>>
>>2013/10/23 Tammo van Lessen <tvanlessen@gmail.com>:
>>> Hi Romain,
>>>
>>> first off, thanks to you and Olivier for taking care of the move from
>>> commons to this place.
>>>
>>> I'm fine with an early release that basically represents the state of
>>> commons. I checked out the sources, ran the tests, fixed one, broke the
>>> build and fixed it again, so my first experience with it was positive ;)
>>> But I still need to try to use it in some real context.
>>>
>>> I'm still new to the API, so I tend to compare it with Coda Hale's metrics.
>>> Am I right, that Sironas Gauges and Coda's Gauges are similar (but with a
>>> slightly different API), but Sirona's Counters are more like Coda's
>>> Histograms, i.e. they hold some statistics like mean, avg etc.? Can you
>>> elaborate a bit how that works? Does it also provide a sampling of the data
>>> in order to keep the memory footprint as small as possible?
>>>
>>> Regarding the reporting GUI, I thought I'm fully with you but I may tend to
>>> disagree. While I like the approach to use a mini framework that does not
>>> interfere with any other components user's projects may use, and while I'm
>>> a ROCA proponent, I think in this case it might really make sense to just
>>> provide a simple but well-though-out RESTful JSON API and a fancy SPA front
>>> end (eg using something like AngularJS), that provides a neat access to
>>> that data. I see several benefits of that approach, e.g. users can use that
>>> UI, but are not limited to it. They can come up with any frontend they like
>>> that is compatible to that API and it is probably easier to come up with a
>>> responsive UI this way instead of serving HTML and JSON for Ajaxy updates.
>>>
>>> I believe it will still remain a Java library, since this is language users
>>> use to integrate it into their code. The typical user will hopefully not
>>> have the need to touch the UI code.
>>>
>>> WDYT?
>>>   Tammo
>>>
>>>
>>> On Wed, Oct 23, 2013 at 9:15 AM, Romain Manni-Bucau
>>> <rmannibucau@gmail.com>wrote:
>>>
>>>> Hi guys!
>>>>
>>>>
>>>> Since Sirona is imported we can now work on trying to get a 0.1-incubating
>>>> out ASAP.
>>>>
>>>> I'd like to release it in these terms:
>>>> 1) core API is not stable but close to be stable - we need to discuss
>>>> Repository maybe
>>>> 2) reporting extensibility is not 100% stable but almost - internals are
>>>> not stable
>>>> 3) other modules can evolve
>>>>
>>>> Here the details about 1 and 2:
>>>>
>>>> 1) Repository
>>>>
>>>> Regarding 1 I think the main point is do we keep the Repository singleton
>>>> like it:
>>>>
>>>> public static final Repository INSTANCE = ...;
>>>>
>>>> Personally I find it ok but we could introduce a RepositoryManager or
>>>> something like that (which would always be the default Impl IMO).
>>>> If somebody is not happy with it please start another thread to fdiscuss +
>>>> ix it.
>>>>
>>>> 2) Reporting/GUI API
>>>>
>>>> ATM the gui is based on a custom mini-framework. First I think it is
>>>> important to reming why we shouldn't rely on server web framework. The main
>>>> point is as a monitoring lib we don't want to modify the app behavior which
>>>> could be the case if we don't do our layer. The next point is we don't need
>>>> that much so it should be fine to redo a thin layer.
>>>>
>>>> About the techno choices. ATM it relies on servlet (we can't really do
>>>> something else which would be consistent with user deployment I think) and
>>>> velocity for base templating engine. ATM this technology is not that
>>>> important and we need to validate or not it.
>>>>
>>>> What is important is the way to extend the GUI. Here are the "constaints" I
>>>> think very important:
>>>> a) it needs to be easy
>>>> b) it needs to be Java (we write a Java lib and Java guys are not all yet
>>>> js ready I think, personally I'd be disappointed to loose time doing my app
>>>> monitoring so I think we should avoid to be too "new" in our choices on
>>>> this aspect)
>>>>
>>>>
>>>> Here how it works ATM:
>>>> a) you implement org.apache.sirona.reporting.web.plugin.Plugin: it defines
>>>> a set of "endpoints" in a subcontext (mappings). The name is used in the
>>>> GUI and internally. You have a single endpoints to keep plugins simple (we
>>>> could handle multiple endpoints by plugin but then the plugin will surely
>>>> be too complicated - open to discuss it but would avoid the "it is cool
>>>> because it is cool technically" thoughts)
>>>> b) endpoint classes: simple java classes with method decorated with
>>>> @org.apache.sirona.reporting.web.handler.api.Regex. If regex value is empty
>>>> we consider it is the home page of the plugin otherwise we consider it as a
>>>> regex and each group will match method parameter (a bit like JAXRS but we
>>>> don't rely on JAXRS to avoid conflict). Endpoint methods return either a
>>>> String which is directly the content of the page (well in fact it is what
>>>> is returned to the client since it is not always a html page) but you can
>>>> return a org.apache.sirona.reporting.web.handler.api.Template too. A
>>>> template has a name (= path to the resource) and a list of parameters
>>>> (variables). The resul is resolved with velocity. Finally endpoint method
>>>> can get url param injected (matched from url) but  request, response and
>>>> TemplateHelper injected too.
>>>> c) to register the plugin just add a META-INF/services/...Plugin
>>>>
>>>> You can have a look to org.apache.sirona.reporting.web.plugin.jta.JTAPlugin
>>>> to get a sample (far easier than reading this mail :p).
>>>>
>>>>
>>>>
>>>> wdyt?
>>>>
>>>>
>>>> *Romain Manni-Bucau*
>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
>>>> *Blog: **http://rmannibucau.wordpress.com/*<
>>>> http://rmannibucau.wordpress.com/>
>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>>>> *Github: https://github.com/rmannibucau*
>>>>
>>>
>>>
>>>
>>> --
>>> Tammo van Lessen - http://www.taval.de
>>
>>
>>