You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Tomasz Oponowicz <to...@gmail.com> on 2010/03/31 00:40:06 UTC
[GSOC][CXF-2736] Proposal for "Simple and lightweight Atom HTML-based
browser for CXF logs"
Hi,
I want to attend the GSOC, and get involved into open source. I chose
project called "Simple and lightweight Atom HTML-based browser for CXF
logs" (CXF-2736) from suggestions in JIRA . Finally I create my
proposal. I guess that Sergey Beryozkin will be mentor for this
project.
- Proposal in ASF wiki:
http://wiki.apache.org/general/soc2010-cxf2736-proposal
- Proposal in GSOC:
http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/tomekopo/t126998466755
Any comments and suggestions are welcome.
Thanks in advance for your feedback.
Best Regards,
Tomasz Oponowicz
Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
HTML-based browser for CXF logs"
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Tomasz
On Thu, Apr 22, 2010 at 4:31 PM, Tomasz Oponowicz <
tomasz.oponowicz@gmail.com> wrote:
> Hi Sergey,
>
> On Thu, Apr 22, 2010 at 3:10 PM, Sergey Beryozkin <sb...@gmail.com>
> wrote:
> > Indeed, at the moment I'm thinking of us starting from something similar
> to
> > "Centralized structure without logs server", it is quite close but not
> > exactly what I've had in mind.
>
> Sorry to bother you. I think it is worth to ask few more question to
> avoid troubles at the end.
>
there's no need to apologize at all :-)
> It's great that we have one vision now.
>
> > The browser application/endpoint will get available say at
> > http://localhost:8080/services/logs and when a users targets this URI
> he/she
> > will be presented with an initial page and then a user will be able to
> > subscribe to individual feeds whose addresses a user will find about from
> > the http://localhost:8080/services page or through some other channels.
>
> This sample is clear. However I would like to consider something.
>
> It's worth to notice that all endpoints (which will interact with log
> browser) have to be on the same host, where initial page (log browser
> page) exist - because of same origin policy [1].
>
>
I do not think it should be a problem. Users would probably have a separate
tab per each host if needed...Lets assume for a start we have a single
host/single container hosting all the endpoints (cxf ones, one/many
AtomPullServer ones plus a browser one). For a case where we have a single
host but multiple containers we can consider utilizing AtomPushBeans
forwarding events to a centralized AtomPullServer or may we will just
recommend opening a tab per each container, we'll see.
thanks, Sergey
> It will be the only limitation of log browser.
>
> [1] http://en.wikipedia.org/wiki/Same_origin_policy
>
> --
> Best regards,
> Tomasz Oponowicz
>
Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
HTML-based browser for CXF logs"
Posted by Tomasz Oponowicz <to...@gmail.com>.
Hi Sergey,
On Thu, Apr 22, 2010 at 3:10 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Indeed, at the moment I'm thinking of us starting from something similar to
> "Centralized structure without logs server", it is quite close but not
> exactly what I've had in mind.
Sorry to bother you. I think it is worth to ask few more question to
avoid troubles at the end.
It's great that we have one vision now.
> The browser application/endpoint will get available say at
> http://localhost:8080/services/logs and when a users targets this URI he/she
> will be presented with an initial page and then a user will be able to
> subscribe to individual feeds whose addresses a user will find about from
> the http://localhost:8080/services page or through some other channels.
This sample is clear. However I would like to consider something.
It's worth to notice that all endpoints (which will interact with log
browser) have to be on the same host, where initial page (log browser
page) exist - because of same origin policy [1].
It will be the only limitation of log browser.
[1] http://en.wikipedia.org/wiki/Same_origin_policy
--
Best regards,
Tomasz Oponowicz
Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
HTML-based browser for CXF logs"
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Tomasz
On Wed, Apr 21, 2010 at 11:27 PM, Tomasz Oponowicz <
tomasz.oponowicz@gmail.com> wrote:
> Hi Segey,
>
> I gather all our ideas in one place and create "concept overview"
> document [1]. I think "Centralized structure without logs server"
> concept is what we are looking for. However if there will be enough
> time I can extend implementation to "Centralized structure with logs
> server" concept. Of course some of presented function are not
> implemented. Please let me know what are you thinking about this.
>
>
Indeed, at the moment I'm thinking of us starting from something similar to
"Centralized structure without logs server", it is quite close but not
exactly what I've had in mind.
First, I'd propose that we do not deal with AtomPushBeans at the moment,
just to make things simpler. The idea behind AtomPushBeans is to push
events immediately to an Atom aware sink/feed and they will likely play
their part in your project too at some later stage, if you'll have time
left, or mat be even after it completes :-).
But at the moment lets start from the assumption that CXF endpoints which
are logging, AtomPullServers which are collecting the log events, and the
"Application1" (as in your diagram) which acts as a browser endpoint are all
collocated in one server. And no AtomPushBeans just yet. Also, IMHO it would
be more precise if the connection between "Application1" and AtomPullServer
was represented by a dotted line directed toward AtomPullServer, meaining
that the browser "Application1" is not really managing or controls
AtomPullServer but kind of depends on them.
Here are so more details which I hope can clarify what I mean.
The relationship between AtomPullServer and CXF endpoints is not one to one.
Users can have one feed matching a single CXF endpoint (logs) or a single
AtomPullServer can be configured such that it collects the log events from
multiple CXF endpoints.
As far as our browser app is concerned, we don't know about the relationship
between AtomPullServer and CXF endpoints.
The browser application/endpoint will get available say at
http://localhost:8080/services/logs and when a users targets this URI he/she
will be presented with an initial page and then a user will be able to
subscribe to individual feeds whose addresses a user will find about from
the http://localhost:8080/services page or through some other channels.
If it is not the first time when a user goes to
http://localhost:8080/services/logs then this user may get presented with
the list of feeds(one or more AtomPullServer endpoint addresses) persisted
in the local storage by "Application1", provided those endpoints 'survived'
the restart. So the only role "Application1" plays is presenting a user with
the initial/starting page, and possibly persisting the subscriptions
somehow, etc.
I hope that going this direction will help you focus better on the actual
browser application. And then once it is all working nicely, we can continue
with introducing AtomPushBeans into the picture and targeting more advanced
deployment scenarious
thanks, Sergey
Before I prepare detailed documentation (with use cases, sequence
> diagram etc.) I must where are we going.
>
> [1] http://wiki.apache.org/general/cxf-logs-browser-concept-overview
>
> On Mon, Apr 19, 2010 at 5:01 PM, Sergey Beryozkin <sb...@gmail.com>
> wrote:
> > Hi Tomasz
> >
> > On Mon, Apr 19, 2010 at 10:13 AM, Tomasz Oponowicz <
> > tomasz.oponowicz@gmail.com> wrote:
> >
> >> Hi Sergey,
> >>
> >> Thanks for your replay and sorry for my delay. I've been offline for a
> >> while. I add more comments below.
> >>
> >
> > no problems at all, please feel free to reply whenever you have some time
> >
> >
> >>
> >> On Fri, Apr 16, 2010 at 4:25 PM, Sergey Beryozkin <sberyozkin@gmail.com
> >
> >> wrote:
> >> > 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.
> >> >
> >>
> >> RSSBandit has exactly layout that I think about. For sure, the browser
> >> will be web application (based on AJAX, JavaScript, JQuery, CSS, XSLT
> >> technologies) - not standalone application (based on Swing
> >> technology). However I'm going to prepare draft documentation to the
> >> end of this month. Documentation will contain uses cases, data flow
> >> diagram and sample screenshots.
> >>
> >
> > Excellent.
> >
> >
> >>
> >> > 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
> >>
> >> We should think about a way how to store an additional data
> >> (subscribed feeds, user credentials etc.). The most obvious solution -
> >> browser can store data in:
> >>
> >> - cookies
> >> - local storage (introduced by HTML 5 [1]).
> >>
> >> I would prefer "local storage", but it isn't supported by any Internet
> >> Explorer (only Safari, Firefox, Google Chrome and Opera support this).
> >>
> >> What you think about this?
> >>
> >>
> >
> > I guess I'd for cookies then and we can move to a better solution once we
> > can see browsers starting to adopt HTML5 and its local storage feature in
> > particular.
> >
> > This actually raises another question. How will our 'browser' get started
> ?
> > I actually haven't even thought about it. Perhaps in the back of my mind
> > I've been assuming it will be indeed our own simple implementation (basic
> > Swing application with HTML-aware panels) - this could be one option
> after
> > all. If we went this route then a user could've started a browser using
> > "java -jar ...". But I'm not insisting, let just keep this option in
> mind.
> >
> > But using an existing browser can be much simpler and may be it is the
> best
> > option indeed. So the question is then how a user will go to the initial
> > page.
> >
> > At the moment, one way for a user to subscribe to all existing CXF
> > AtomPullServer endpoints is to go to a CXF /services page and select the
> > links to AtomPullServer endpoints, the links will be there if a user has
> > chosen to make them visible, by configuring individual AtomPullServer
> > endpoints. So I thought that perhaps we could also have a link from the
> > /services page to an Atom Service document describing all the
> AtomPullServer
> > endpoints currently visible/available. Or may be we can have it available
> at
> > say /services/logs. Having such a document would let our browser to see
> an
> > uptodate view/list of the existing log feeds.
> >
> > So one reliable way to 'restore' the previous subscriptions after either
> a
> > browser or a container hosting the feeds has been restarted is for a user
> to
> > copy the links from a /services page or direct a browser to
> /services/logs,
> > when it becomes available. It is a primitive option but it will work.
> >
> > However, it is still not clear how a user will go to the initial browser
> > page. After talking aloud here I'm just coming to the conclusion that may
> be
> > rt/management-web should have another CXF JAXRS endpoint which will act
> as
> > the browser bootstrapping/storage point.
> >
> > So this endpoints is registered at the well known '/services/logs'
> address
> > and when a user selects say http://host:8080/services/logs, our initial
> page
> > is served by this 'browser' endpoint. A user then subscribes to
> individual
> > log feeds and possibly gets authenticated and views the logs. Here, a
> user
> > can subscribe as suggested above, by copying the feed links from the
> > /services page or copying the link to the atom services document. (In the
> > future, a browser, after getting a link from a user to the /services
> page,
> > may be abe to parse the resulting page and offer a choice of feed links
> to a
> > user using some drop down list...).
> >
> > Now, when a browser exits, we can let user (initially) restore the
> > subscriptions the same way as those subscriptions were made originally,
> by
> > copying the links, etc. Perhaps, in the typical application, there would
> be
> > just a couple of such links. Or we can try storing the subscriptions by
> > having a browser posting a final request to the 'backing' endpoint, or
> may
> > be just use the cookies if it what the user asks for.
> >
> > Not sure if we can avoid creating a 'browser' CXF JAXRS endpoint. Seems
> like
> > the simplest but viable option.
> >
> > what do you think ?
> >
> > thanks, Sergey
> >
> >
> >>
> >> [1] http://apirocks.com/html5/html5.html#slide7
> >>
> >> --
> >> Best Regards,
> >> Tomasz Oponowicz
> >>
> >
>
>
>
> --
> Pozdrawiam,
> Tomasz Oponowicz
>
Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
HTML-based browser for CXF logs"
Posted by Tomasz Oponowicz <to...@gmail.com>.
Hi Segey,
I gather all our ideas in one place and create "concept overview"
document [1]. I think "Centralized structure without logs server"
concept is what we are looking for. However if there will be enough
time I can extend implementation to "Centralized structure with logs
server" concept. Of course some of presented function are not
implemented. Please let me know what are you thinking about this.
Before I prepare detailed documentation (with use cases, sequence
diagram etc.) I must where are we going.
[1] http://wiki.apache.org/general/cxf-logs-browser-concept-overview
On Mon, Apr 19, 2010 at 5:01 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Tomasz
>
> On Mon, Apr 19, 2010 at 10:13 AM, Tomasz Oponowicz <
> tomasz.oponowicz@gmail.com> wrote:
>
>> Hi Sergey,
>>
>> Thanks for your replay and sorry for my delay. I've been offline for a
>> while. I add more comments below.
>>
>
> no problems at all, please feel free to reply whenever you have some time
>
>
>>
>> On Fri, Apr 16, 2010 at 4:25 PM, Sergey Beryozkin <sb...@gmail.com>
>> wrote:
>> > 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.
>> >
>>
>> RSSBandit has exactly layout that I think about. For sure, the browser
>> will be web application (based on AJAX, JavaScript, JQuery, CSS, XSLT
>> technologies) - not standalone application (based on Swing
>> technology). However I'm going to prepare draft documentation to the
>> end of this month. Documentation will contain uses cases, data flow
>> diagram and sample screenshots.
>>
>
> Excellent.
>
>
>>
>> > 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
>>
>> We should think about a way how to store an additional data
>> (subscribed feeds, user credentials etc.). The most obvious solution -
>> browser can store data in:
>>
>> - cookies
>> - local storage (introduced by HTML 5 [1]).
>>
>> I would prefer "local storage", but it isn't supported by any Internet
>> Explorer (only Safari, Firefox, Google Chrome and Opera support this).
>>
>> What you think about this?
>>
>>
>
> I guess I'd for cookies then and we can move to a better solution once we
> can see browsers starting to adopt HTML5 and its local storage feature in
> particular.
>
> This actually raises another question. How will our 'browser' get started ?
> I actually haven't even thought about it. Perhaps in the back of my mind
> I've been assuming it will be indeed our own simple implementation (basic
> Swing application with HTML-aware panels) - this could be one option after
> all. If we went this route then a user could've started a browser using
> "java -jar ...". But I'm not insisting, let just keep this option in mind.
>
> But using an existing browser can be much simpler and may be it is the best
> option indeed. So the question is then how a user will go to the initial
> page.
>
> At the moment, one way for a user to subscribe to all existing CXF
> AtomPullServer endpoints is to go to a CXF /services page and select the
> links to AtomPullServer endpoints, the links will be there if a user has
> chosen to make them visible, by configuring individual AtomPullServer
> endpoints. So I thought that perhaps we could also have a link from the
> /services page to an Atom Service document describing all the AtomPullServer
> endpoints currently visible/available. Or may be we can have it available at
> say /services/logs. Having such a document would let our browser to see an
> uptodate view/list of the existing log feeds.
>
> So one reliable way to 'restore' the previous subscriptions after either a
> browser or a container hosting the feeds has been restarted is for a user to
> copy the links from a /services page or direct a browser to /services/logs,
> when it becomes available. It is a primitive option but it will work.
>
> However, it is still not clear how a user will go to the initial browser
> page. After talking aloud here I'm just coming to the conclusion that may be
> rt/management-web should have another CXF JAXRS endpoint which will act as
> the browser bootstrapping/storage point.
>
> So this endpoints is registered at the well known '/services/logs' address
> and when a user selects say http://host:8080/services/logs, our initial page
> is served by this 'browser' endpoint. A user then subscribes to individual
> log feeds and possibly gets authenticated and views the logs. Here, a user
> can subscribe as suggested above, by copying the feed links from the
> /services page or copying the link to the atom services document. (In the
> future, a browser, after getting a link from a user to the /services page,
> may be abe to parse the resulting page and offer a choice of feed links to a
> user using some drop down list...).
>
> Now, when a browser exits, we can let user (initially) restore the
> subscriptions the same way as those subscriptions were made originally, by
> copying the links, etc. Perhaps, in the typical application, there would be
> just a couple of such links. Or we can try storing the subscriptions by
> having a browser posting a final request to the 'backing' endpoint, or may
> be just use the cookies if it what the user asks for.
>
> Not sure if we can avoid creating a 'browser' CXF JAXRS endpoint. Seems like
> the simplest but viable option.
>
> what do you think ?
>
> thanks, Sergey
>
>
>>
>> [1] http://apirocks.com/html5/html5.html#slide7
>>
>> --
>> Best Regards,
>> Tomasz Oponowicz
>>
>
--
Pozdrawiam,
Tomasz Oponowicz
Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
HTML-based browser for CXF logs"
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Tomasz
On Mon, Apr 19, 2010 at 10:13 AM, Tomasz Oponowicz <
tomasz.oponowicz@gmail.com> wrote:
> Hi Sergey,
>
> Thanks for your replay and sorry for my delay. I've been offline for a
> while. I add more comments below.
>
no problems at all, please feel free to reply whenever you have some time
>
> On Fri, Apr 16, 2010 at 4:25 PM, Sergey Beryozkin <sb...@gmail.com>
> wrote:
> > 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.
> >
>
> RSSBandit has exactly layout that I think about. For sure, the browser
> will be web application (based on AJAX, JavaScript, JQuery, CSS, XSLT
> technologies) - not standalone application (based on Swing
> technology). However I'm going to prepare draft documentation to the
> end of this month. Documentation will contain uses cases, data flow
> diagram and sample screenshots.
>
Excellent.
>
> > 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
>
> We should think about a way how to store an additional data
> (subscribed feeds, user credentials etc.). The most obvious solution -
> browser can store data in:
>
> - cookies
> - local storage (introduced by HTML 5 [1]).
>
> I would prefer "local storage", but it isn't supported by any Internet
> Explorer (only Safari, Firefox, Google Chrome and Opera support this).
>
> What you think about this?
>
>
I guess I'd for cookies then and we can move to a better solution once we
can see browsers starting to adopt HTML5 and its local storage feature in
particular.
This actually raises another question. How will our 'browser' get started ?
I actually haven't even thought about it. Perhaps in the back of my mind
I've been assuming it will be indeed our own simple implementation (basic
Swing application with HTML-aware panels) - this could be one option after
all. If we went this route then a user could've started a browser using
"java -jar ...". But I'm not insisting, let just keep this option in mind.
But using an existing browser can be much simpler and may be it is the best
option indeed. So the question is then how a user will go to the initial
page.
At the moment, one way for a user to subscribe to all existing CXF
AtomPullServer endpoints is to go to a CXF /services page and select the
links to AtomPullServer endpoints, the links will be there if a user has
chosen to make them visible, by configuring individual AtomPullServer
endpoints. So I thought that perhaps we could also have a link from the
/services page to an Atom Service document describing all the AtomPullServer
endpoints currently visible/available. Or may be we can have it available at
say /services/logs. Having such a document would let our browser to see an
uptodate view/list of the existing log feeds.
So one reliable way to 'restore' the previous subscriptions after either a
browser or a container hosting the feeds has been restarted is for a user to
copy the links from a /services page or direct a browser to /services/logs,
when it becomes available. It is a primitive option but it will work.
However, it is still not clear how a user will go to the initial browser
page. After talking aloud here I'm just coming to the conclusion that may be
rt/management-web should have another CXF JAXRS endpoint which will act as
the browser bootstrapping/storage point.
So this endpoints is registered at the well known '/services/logs' address
and when a user selects say http://host:8080/services/logs, our initial page
is served by this 'browser' endpoint. A user then subscribes to individual
log feeds and possibly gets authenticated and views the logs. Here, a user
can subscribe as suggested above, by copying the feed links from the
/services page or copying the link to the atom services document. (In the
future, a browser, after getting a link from a user to the /services page,
may be abe to parse the resulting page and offer a choice of feed links to a
user using some drop down list...).
Now, when a browser exits, we can let user (initially) restore the
subscriptions the same way as those subscriptions were made originally, by
copying the links, etc. Perhaps, in the typical application, there would be
just a couple of such links. Or we can try storing the subscriptions by
having a browser posting a final request to the 'backing' endpoint, or may
be just use the cookies if it what the user asks for.
Not sure if we can avoid creating a 'browser' CXF JAXRS endpoint. Seems like
the simplest but viable option.
what do you think ?
thanks, Sergey
>
> [1] http://apirocks.com/html5/html5.html#slide7
>
> --
> Best Regards,
> Tomasz Oponowicz
>
Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
HTML-based browser for CXF logs"
Posted by Tomasz Oponowicz <to...@gmail.com>.
Hi Sergey,
Thanks for your replay and sorry for my delay. I've been offline for a
while. I add more comments below.
On Fri, Apr 16, 2010 at 4:25 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> 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.
>
RSSBandit has exactly layout that I think about. For sure, the browser
will be web application (based on AJAX, JavaScript, JQuery, CSS, XSLT
technologies) - not standalone application (based on Swing
technology). However I'm going to prepare draft documentation to the
end of this month. Documentation will contain uses cases, data flow
diagram and sample screenshots.
> 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
We should think about a way how to store an additional data
(subscribed feeds, user credentials etc.). The most obvious solution -
browser can store data in:
- cookies
- local storage (introduced by HTML 5 [1]).
I would prefer "local storage", but it isn't supported by any Internet
Explorer (only Safari, Firefox, Google Chrome and Opera support this).
What you think about this?
> 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.
>
I understood everything.
> 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
>
[1] http://apirocks.com/html5/html5.html#slide7
--
Best Regards,
Tomasz Oponowicz
Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
HTML-based browser for CXF logs"
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>
Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
HTML-based browser for CXF logs"
Posted by Tomasz Oponowicz <to...@gmail.com>.
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
Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
HTML-based browser for CXF logs"
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Tomasz
On Fri, Apr 2, 2010 at 10:18 AM, Tomasz Oponowicz <
tomasz.oponowicz@gmail.com> wrote:
> Hi Sergey,
>
> I have prepared sample project using AtomPullServer (base on CXF
> 2.3.0-SNAPSHOT). I successful published Atom feed with CXF logs. Now I
> understand clearly your requirments.
>
it's good you've independently verified that the publication works, thanks.
>
> I have updated my proporsal (at ASF wiki and GSOC 2010 website), changes:
> - Noted about AtomPullServer;
> - Added requirement with respect to implementation of
> ReadWriteLogStorage interface;
>
I think it is something that an AtomPullServer demo could do, that is, show
how a custom
ReadWriteLogStorage can be used to persist records across the restarts. When
reading (only) from the external file, a custom ReadableLogStorage can be
used instead. 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. So perhaps you can have
an optional task to do with adding a demo showing how a user could start a
browser, point it to an AtomPullServer endpoint, and view the logs from some
external file (using ReadableStorage), and then point to another endpoint
which uses ReadWriteLogStorage
- Added Atom authentication requirement;
>
I've been thinking for a while of adding some cxf jaxrs code for handling
WSSE UserName HTTP headers (as opposed to SOAP headers) so that the regular
JAXRS endpoints could do such authentication over plain HTTP too (using
digest), so AtomPullServer will reuse that code (as opposed to bringing an
extra abdera dependency for handling wsse username headers).
> - Fixed language mistakes;
>
> I hope everything is fine now.
>
It all looks very good. A couple of comments:
- IMHO using links as opposed to buttons will be better (for browsing to
first/last/etc feeds)
- The browser should offer users an option to do the search (ex, get all the
records with level INFO logged by a given component between 12.10.2010 14.50
and 12.10.2010 15.00). After collecting a requirement from a user, the
browser will convert it into a FIQL query and issue a request (please see
http://sberyozkin.blogspot.com/2010/03/cxf-jaxrs-search-extensions.html).
This probably can be captured by your 'filtering' task. I'll actually need
to enhance AtomPullServer too for such queries be supported...
thanks, Sergey
> Best Regards,
> Tomasz Oponowicz
>
> On Wed, Mar 31, 2010 at 2:15 PM, Sergey Beryozkin <sb...@gmail.com>
> wrote:
> > Hi Tomasz
> >
> > thanks for your interest. I'd be happy to be a mentor.
> >
> > Just a couple of clarifications with respect to your proposal :
> >
> > - CXF JAXRS endpoint acting as an Atom Pull server has already been added
> to
> > a rt/management component, I've briefly described it here :
> >
> http://sberyozkin.blogspot.com/2010/02/use-your-favorite-atom-reader-to-view.html
> .
> > I'll make sure that by the time you start working on this project the
> > documentation will be up-to-date. To my knowledge, no existing atom
> readers
> > support the paged/archived feeds well, thus the idea for the OTB browser
> has
> > come up. Indeed, as you mentioned in your proposal, the same browser may
> be
> > extended later on to support the viewing of the CXF exchanges, it is for
> > this latter task when a dedicated CXF JAXRS endpoint will have to be
> added.
> >
> > - The question of security will need to be addressed as well. Most likely
> > we'll need to use a WSSE UserToken for the Atom authentication, basic
> > authentication over HTTPs may not be a practical solution for viewing the
> > logs...
> >
> > Please post your ideas/questions to this thread when you start working
> and
> > we'll be glad to help
> > cheers, Sergey
> >
> >
> >
> > On Tue, Mar 30, 2010 at 11:40 PM, Tomasz Oponowicz <
> > tomasz.oponowicz@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I want to attend the GSOC, and get involved into open source. I chose
> >> project called "Simple and lightweight Atom HTML-based browser for CXF
> >> logs" (CXF-2736) from suggestions in JIRA . Finally I create my
> >> proposal. I guess that Sergey Beryozkin will be mentor for this
> >> project.
> >>
> >> - Proposal in ASF wiki:
> >> http://wiki.apache.org/general/soc2010-cxf2736-proposal
> >>
> >> - Proposal in GSOC:
> >>
> >>
> http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/tomekopo/t126998466755
> >>
> >> Any comments and suggestions are welcome.
> >> Thanks in advance for your feedback.
> >>
> >> Best Regards,
> >> Tomasz Oponowicz
> >>
> >
>
>
>
> --
> Pozdrawiam,
> Tomasz Oponowicz
>
Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
HTML-based browser for CXF logs"
Posted by Tomasz Oponowicz <to...@gmail.com>.
Hi Sergey,
I have prepared sample project using AtomPullServer (base on CXF
2.3.0-SNAPSHOT). I successful published Atom feed with CXF logs. Now I
understand clearly your requirments.
I have updated my proporsal (at ASF wiki and GSOC 2010 website), changes:
- Noted about AtomPullServer;
- Added requirement with respect to implementation of
ReadWriteLogStorage interface;
- Added Atom authentication requirement;
- Fixed language mistakes;
I hope everything is fine now.
Best Regards,
Tomasz Oponowicz
On Wed, Mar 31, 2010 at 2:15 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Tomasz
>
> thanks for your interest. I'd be happy to be a mentor.
>
> Just a couple of clarifications with respect to your proposal :
>
> - CXF JAXRS endpoint acting as an Atom Pull server has already been added to
> a rt/management component, I've briefly described it here :
> http://sberyozkin.blogspot.com/2010/02/use-your-favorite-atom-reader-to-view.html.
> I'll make sure that by the time you start working on this project the
> documentation will be up-to-date. To my knowledge, no existing atom readers
> support the paged/archived feeds well, thus the idea for the OTB browser has
> come up. Indeed, as you mentioned in your proposal, the same browser may be
> extended later on to support the viewing of the CXF exchanges, it is for
> this latter task when a dedicated CXF JAXRS endpoint will have to be added.
>
> - The question of security will need to be addressed as well. Most likely
> we'll need to use a WSSE UserToken for the Atom authentication, basic
> authentication over HTTPs may not be a practical solution for viewing the
> logs...
>
> Please post your ideas/questions to this thread when you start working and
> we'll be glad to help
> cheers, Sergey
>
>
>
> On Tue, Mar 30, 2010 at 11:40 PM, Tomasz Oponowicz <
> tomasz.oponowicz@gmail.com> wrote:
>
>> Hi,
>>
>> I want to attend the GSOC, and get involved into open source. I chose
>> project called "Simple and lightweight Atom HTML-based browser for CXF
>> logs" (CXF-2736) from suggestions in JIRA . Finally I create my
>> proposal. I guess that Sergey Beryozkin will be mentor for this
>> project.
>>
>> - Proposal in ASF wiki:
>> http://wiki.apache.org/general/soc2010-cxf2736-proposal
>>
>> - Proposal in GSOC:
>>
>> http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/tomekopo/t126998466755
>>
>> Any comments and suggestions are welcome.
>> Thanks in advance for your feedback.
>>
>> Best Regards,
>> Tomasz Oponowicz
>>
>
--
Pozdrawiam,
Tomasz Oponowicz
Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
HTML-based browser for CXF logs"
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Tomasz
thanks for your interest. I'd be happy to be a mentor.
Just a couple of clarifications with respect to your proposal :
- CXF JAXRS endpoint acting as an Atom Pull server has already been added to
a rt/management component, I've briefly described it here :
http://sberyozkin.blogspot.com/2010/02/use-your-favorite-atom-reader-to-view.html.
I'll make sure that by the time you start working on this project the
documentation will be up-to-date. To my knowledge, no existing atom readers
support the paged/archived feeds well, thus the idea for the OTB browser has
come up. Indeed, as you mentioned in your proposal, the same browser may be
extended later on to support the viewing of the CXF exchanges, it is for
this latter task when a dedicated CXF JAXRS endpoint will have to be added.
- The question of security will need to be addressed as well. Most likely
we'll need to use a WSSE UserToken for the Atom authentication, basic
authentication over HTTPs may not be a practical solution for viewing the
logs...
Please post your ideas/questions to this thread when you start working and
we'll be glad to help
cheers, Sergey
On Tue, Mar 30, 2010 at 11:40 PM, Tomasz Oponowicz <
tomasz.oponowicz@gmail.com> wrote:
> Hi,
>
> I want to attend the GSOC, and get involved into open source. I chose
> project called "Simple and lightweight Atom HTML-based browser for CXF
> logs" (CXF-2736) from suggestions in JIRA . Finally I create my
> proposal. I guess that Sergey Beryozkin will be mentor for this
> project.
>
> - Proposal in ASF wiki:
> http://wiki.apache.org/general/soc2010-cxf2736-proposal
>
> - Proposal in GSOC:
>
> http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/tomekopo/t126998466755
>
> Any comments and suggestions are welcome.
> Thanks in advance for your feedback.
>
> Best Regards,
> Tomasz Oponowicz
>