cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomasz Oponowicz <tomasz.oponow...@gmail.com>
Subject Re: [GSOC] Simple and lightweight HTML-based browser for surveying Apache CXF logs
Date Thu, 15 Jul 2010 11:55:45 GMT
Hi Sergey,

Thanks for your reply. More comments below.

On Wed, Jul 14, 2010 at 12:22 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
> - please consider updating the demo so that the real log entries are
> generated; that is, introduce a basic CXF JAXRS endpoint (or JAXWS endpoint)
> with one or two methods returning some html or xml data and doing some
> logging, and have a user invoking on that endpoint, using a browser, same as
> a user does now when invoking on the generate servlet. The log events
> generated by the endpoints should be caught by the AtomPullServerEndpoint
> and eventually displayed in the browser window (through Refresh for a
> start).

It's great idea. User can see how exactly it'll look like and also he
doesn't have to add log entries by himself.

> - how do you consider letting users browse through the entries given that a
> number of entries to be displayed on a page is limited - there should be
> first/previous/next/last links.

This is already implemented. first/previous/next/last links are
visible or hidden depend on response from AtomPullServer.

For example:

<feed xmlns="http://www.w3.org/2005/Atom">
    [...]
    <link href="http://localhost:8888/log/logs" rel="self"/>
    <link href="http://localhost:8888/log/logs/alternate/1" rel="alternate"/>
    <link href="http://localhost:8888/log/logs/2" rel="next"/>
    <link href="http://localhost:8888/log/logs/4" rel="last"/>
    [...]
</feed>

There are visible only refresh, next and last links. first and
previous links are hidden.

[...]

You can easily test it (because of custom MockReadableLogStorage) when you type:

mvn gwt:run -Pdev

and than go to address in web browser:

http://127.0.0.1:8888/logbrowser/LogBrowser.html?gwt.codesvr=127.0.0.1:9997

> - The actual log entry info (displayed in the right - bottom view) should
> not include date/time - this is already shown in the right-top view; only
> the actual content

Ok, this is quick fix.

> there're few other enhancements I'd  like to discuss - but for now please
> address the above comments - let me know if you have any doubts, etc.
>
> As I said - this is a very good effort on your behalf - thanks
> Sergey
>
>
> On Thu, Jul 8, 2010 at 5:22 PM, Sergey Beryozkin <sberyozkin@gmail.com>wrote:
>
> > Hi Tomasz
> >
> >  > See, I'm not proposing to write a new servlet implementation. First, I'd
> >> > like to understand what you were trying to achieve by introducing
> >> > StaticContentServlet - I can see it's about serving the static content
-
> >> but
> >> > what type of content, when exactly it is needed ? Next, I'd like to see
> >> if
> >> > either AbstractHttpServlet [1] or BootstrapStorage endpoint can be
> >> enhanced
> >> > to do what  StaticContentServlet does ?
> >>
> >> At the moment we've got java classes and *.ui.xml files, which are
> >> changed respectively into *.js and *.css files by GWT compiler (it
> >> change java code to javascript).
> >> To be more specified it's done by 'gwt-maven-plugin'. The GWT
> >> dependency has compilation scope - we don't use GWT at runtime. All
> >> these static files are packed into jar file (static flies takes about
> >> 0.5MB).  Because classes from package
> >> "org.apache.cxf.management.web.logging.browser.client.*" are no longer
> >> needed, they aren't packed into jar file.
> >>
> >> Before user can use our LogBrowser, he has to retrieve all HTML, JS
> >> and CSS files - it can be simply done by go to URL (for example):
> >>
> >> <localhost>/logbrowser/LogBrowser.html
> >>
> >> This content is served by StaticContentServlet - the static files are
> >> retrieve from jar file and send as HTTP response. These happens only
> >> once (per browser) because all of these files are highly cached. After
> >> that user sign in and retrieve settings using BootstrapStorage
> >> endpoint.
> >>
> >> thanks for the explanation
> >
> >
> >> However StaticContentServlet and BootstrapStorage endpoints do similar
> >> job - they "init" application. I think extending BootstrapStorage (to
> >> add StaticContentServlet functionality) will be the best solution.
> >>
> >> What do you think about that?
> >>
> >>
> > Please start from having a dedicated resource method in BootstrapStorage
> > endpoint - this is the simplest thing to do at this stage and it should not
> > be time consuming, but perhaps at some later stage AbstractHttpServlet may
> > be enhanced a bit too..
> >
> > thanks, Sergey
> >



--
Best regards,
Tomasz Oponowicz

Mime
View raw message