cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom HTML-based browser for CXF logs"
Date Fri, 16 Apr 2010 14:25:15 GMT
Hi Tomasz

If you can, please experiment with RSSBandit Atom reader on Windows, I used
it when testing Atom logging feeds and I thought it was quite close to how
I'd expect the views be partitioned.

The left hand panel lists the individual CXF endpoint feeds, a user will
create new subscriptions by specifying atom pull server endpoint addresses
and provide the username/password if needed. Later on we can think of
introducing an Atom services document which will show all the current
collection of CXF log feeds, but this can be done later.

The top-right one represents a current feed page for an individual CXF
endpoint log feed (selected by clicking on the left plane) and lists the
links to individual log entries and this is where I'd expect the links to
previous/next/etc pages to be located. Currently, AtomPullServer builds some
primitive HTML page (without the links, or may even with ?) internally which
represents the current feed page in HTML, so this page will need to be
improved to have the links added and the styles attached, perhaps by
introducing some CSS and XSLT resources.

The bottom-right one represents a selected log entry (selected in the
current feed page above). Again, AtomPullServer creates a primitive HTML
page too for representing a selected entry.

Another possible (optional) enhancement to consider (only if you have some
time left, really not critical) : this browser acts as the feed as well to
which CXF AtomPush loggers will push too. Here is the idea. By default the
browser will poll the individual feeds. The frequency may have to be quite
small, say every 30 secs or 60 secs or whatever the user selects to ensure a
user/admin sees the uptodate picture. Now, this might put some pressure on
the actual application servers where JAXWS/JAXRS endpoints doing the actual
logging are published.

One simple approach to solve that issue is to simply have a separate
container running AtomPullServers only and the other container(s) (which
host application endpoints) relying on AtomPushBeans posting log entries
oneway to AtomPullServers - our browser will poll the latter one and some
very limited pressure will be applied on the application containers.
WebClientDeliverer utilized by AtomPushBeans will need to be updated
slightly to optionally add @Oneway headers to outgoing requests, if
configured so.

Now another option is for a browser to have a small window which sits right
below the windows mentioned above and which simply outputs the latest log
entry titles (no content, just titles) using FIFO, without storing anything.
The idea is that the application server which uses AtomPullServers ( which
our browser keeps polling) also employs a Oneway AtomPushBean to post most
important events (ERROR/WARN, etc) to the master feed (which what our
browser acts as too in this case). This can let the browser poll the
endpoint say every 4-5 mins thus reducing the pressure on the container but
also indicate to a user (by displaying the event in this window) that the
feed page may need to be refreshed manually...

As I said, it can be addressed later on...

Finally AtomPullServer will need to be enhanced slightly to support
conditional GETS, but this is an easy one (so I hope :-)).

thanks, Sergey

On Sat, Apr 3, 2010 at 6:33 PM, Tomasz Oponowicz <tomasz.oponowicz@gmail.com
> wrote:

> Hi Sergey,
>
> Thanks for your comments.
>
> I have updated my proposal (at ASF wiki and GSOC 2010 website) with
> respect to your comments.
>
> > I'm not sure if we can come up with production-quality default
> > implementation, perhaps a file-based ReadWriteLogStorage can be provided
> > OTB, but there's no way we can have a default ReadableOnlyStorage,
> perhaps
> > the abstract helper only, given that users's code can log into external
> > files using log4j, jul, sl4j, using various formats.
>
> I agree that production-quality default implementation of
> ReadWriteLogStorage or ReadableLogStorage interface could be
> problematic. Removed this requirement from my proposal. However I
> noted about abstract helper dedicated for ReadWriteLogStorage and
> ReadableLogStorage interface.
>
> > IMHO using links as opposed to buttons will be better (for browsing to
> >  first/last/etc feeds)
>
> Fixed.
>
> > The browser should offer users an option to do the search
>
> It is great idea to use FIQL query. I have updated my proposal and
> noted about custom filtering requirement (by phrase, event log, date
> range etc) using FIQL to build queries.
>
> Best Regards,
> Tomasz Oponowicz
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message