Re: [GSOC][CXF-2736] Proposal for Simple and lightweight Atom HTML-based browser for CXF logs
Hi Tomasz On Wed, Apr 21, 2010 at 11:27 PM, Tomasz Oponowicz tomasz.oponow...@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 sberyoz...@gmail.com wrote: Hi Tomasz On Mon, Apr 19, 2010 at 10:13 AM, Tomasz Oponowicz tomasz.oponow...@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 sberyoz...@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
Re: [GSOC][CXF-2736] Proposal for Simple and lightweight Atom HTML-based browser for CXF logs
Hi Sergey, On Thu, Apr 22, 2010 at 3:10 PM, Sergey Beryozkin sberyoz...@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
Hi Tomasz On Thu, Apr 22, 2010 at 4:31 PM, Tomasz Oponowicz tomasz.oponow...@gmail.com wrote: Hi Sergey, On Thu, Apr 22, 2010 at 3:10 PM, Sergey Beryozkin sberyoz...@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
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 sberyoz...@gmail.com wrote: Hi Tomasz On Mon, Apr 19, 2010 at 10:13 AM, Tomasz Oponowicz tomasz.oponow...@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 sberyoz...@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
Re: [GSOC][CXF-2736] Proposal for Simple and lightweight Atom HTML-based browser for CXF logs
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 sberyoz...@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
Hi Tomasz On Mon, Apr 19, 2010 at 10:13 AM, Tomasz Oponowicz tomasz.oponow...@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 sberyoz...@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
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.oponow...@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
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
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 sberyoz...@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.oponow...@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
Hi Tomasz On Fri, Apr 2, 2010 at 10:18 AM, Tomasz Oponowicz tomasz.oponow...@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 sberyoz...@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.oponow...@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
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.oponow...@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
