Hi all, I think what you suggest is a good idea. I am quite familiar with WSO2 Online Support System now, but I am quite new to WSO2-DAS. I went through the http://wso2.com/products/data-analytics-server/ website to get a basic idea on what WSO2-DAS is about. I will refer more to get a clear picture on how it works.
Thanks and regards Nathiesha On Tue, Jun 7, 2016 at 7:12 PM, Susinda Perera <susi...@wso2.com> wrote: > Hi All > > How about configuring wso2-DAS at the wso2 side to collect and analyse > error/logs. It is not only reporting to wso2 JIRA, it may be some other > system so 'reporting to' should be an configurable and pluggable feature. > If we are publishing to DAS, we have to come up with format for stream > definition, which may need some literature survey on how other log > analysers work etc. > > Thanks > Susinda > > On Tue, Jun 7, 2016 at 3:48 PM, Jasintha Dasanayake <jasin...@wso2.com> > wrote: > >> HI Nathiesha >> >> I couldn't see any commit[1] during the last couple of week, it's good >> practices to do commit stuff daily basis, because it's easy for us to >> review and provide regular feedbacks. >> >> Shall we have a progress review during the next week ?. >> >> Thanks and Regards >> /Jasintha >> >> [1]- >> https://github.com/nathiesha/org.wso2.developerstudio.eclipse.errorreporter.git >> >> On Sat, May 14, 2016 at 6:12 PM, Nathiesha Maddage < >> nathieshamadd...@gmail.com> wrote: >> >>> Hi all, >>> >>> I formatted and cleaned the code and added the licence header. >>> Regarding the naming of the project, I named the project >>> as org.wso2.developerstudio.eclipse.errorreporter for now. And about the >>> packages, I referred to the developer studio plugins projects you have sent >>> me. However as I am still not familiar with the naming conventions for >>> developer studio plugins I temporarily created a couple of packages to >>> group the Java classes. I hope I can do the proper renaming and packaging >>> later with your support. >>> >>> I created the ErrorInfoCollector class and there all the system >>> information and error related information is fetched. However I couldn't >>> find a method to get the plugin version and I am still working on it. And >>> the error report that I have sent you previously had an attribute called >>> fingerprint and it also contained a set of bundle information. Those two >>> parts I could not understand. So I left them for now. >>> As you suggested, this class can be improved later to >>> collect further information regarding the error. >>> >>> I started with preferences page as well. I created a draft preference >>> page and currently working on improving it. >>> >>> This is the new GitHub link of the project repository. Please refer to >>> this afterwards. >>> >>> Link- >>> https://github.com/nathiesha/org.wso2.developerstudio.eclipse.errorreporter.git >>> >>> Thanks and Regards >>> >>> Nathiesha >>> >>> >>> >>> On Fri, May 13, 2016 at 12:26 PM, Kavith Lokuhewage <kav...@wso2.com> >>> wrote: >>> >>>> Hi Nathiesha, >>>> >>>> Please find my inline comments. >>>> >>>> On Wed, May 11, 2016 at 12:10 PM, Nathiesha Maddage < >>>> nathieshamadd...@gmail.com> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Regarding the preference settings, as I have read, the plugins that >>>>> are started early are listed in preferences-general-startup and shutdown >>>>> page. So the user can deselect the plugin from that list and then it will >>>>> not be started once Eclipse starts. Is this what is expected? >>>>> >>>> >>>> No. This is not the expectation. >>>> >>>> Or I can add an option for the user to configure the start up settings >>>>> of the error reporting plugin, in a separate preference page, that I am >>>>> going to develop for the Error Reporting plugin settings. >>>>> >>>> >>>> Yes. This is the expectation. >>>> >>>> >>>>> And regarding the multi status of IStatus, I will look into that and I >>>>> will try to fetch all the previously failed operation information. Here I >>>>> have attached a error report that Eclipse error reporting tool produces. >>>>> Please have a look at the information listed in that report regarding the >>>>> error. As you have mentioned earlier, I will add the previously failed >>>>> operation details if available. Other than previously failed operations >>>>> and >>>>> the information listed in the attached report , what else need to be added >>>>> to the error report? Or is that information sufficient for the development >>>>> team? >>>>> >>>> >>>> For now, we will keep our focus on this information and give priority >>>> to them. However, there's always chance for improvements. Later, if time >>>> permits, we may focus on the aspects such as attaching the artifacts which >>>> could have caused the issue (with the permission of user), information >>>> about project hierarchy, active editor, perspective etc. (we should analyse >>>> the needs for these further), etc. >>>> >>>> >>>>> >>>>> And thank you for the tips about getting the run time details. That >>>>> saved my time. I will try those. And as you have suggested, it is good to >>>>> use the proper coding standards from the beginning. I will get an idea >>>>> from >>>>> the example project you have sent me, and I will refactor the code >>>>> accordingly. >>>>> >>>>> >>>> >>>>> Thanks and regards >>>>> >>>>> Nathiesha >>>>> >>>>> >>>>> >>>>> On Wed, May 11, 2016 at 10:08 AM, Kavith Lokuhewage <kav...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi Nathiesha, >>>>>> >>>>>> Great start! Just some heads up for your next steps. >>>>>> >>>>>> An IStatus instance sometimes could be a multi status instance where >>>>>> you can get other IStatus instances associated with it using the >>>>>> getChildren() method[1]. This simply means that a series of operations >>>>>> failed and information about previously failed operations are also >>>>>> valuable >>>>>> when making the report. >>>>>> >>>>>> There are multiple ways to read java run-time version, the easiest >>>>>> would be to read the system property called "java.runtime.version". >>>>>> >>>>>> Furthermore, org.eclipse.core.runtime.Platform class [2] provides >>>>>> multiple methods to fetch run-time environment information such as OS >>>>>> name, >>>>>> architecture and windowing library etc. It will also be helpful for you >>>>>> fetch additional information about the run-time environment. >>>>>> >>>>>> On a side note, I would suggest that it will be good if you starts >>>>>> coding with the proper coding standards we use, from the beginning. This >>>>>> will reduce the time it takes to refactor the code later, in a great >>>>>> amount. As a start you can refactor the current package hierarchy to a >>>>>> proper package hierarchy we use for developer studio plugins [get an idea >>>>>> from - 3]. >>>>>> >>>>>> I am attaching the license header and eclipse code cleanup and >>>>>> formatting templates for java. >>>>>> Go to Window -> Preferences -> Java-> Code Style >>>>>> 1. Set attached templates as cleanup and formatting >>>>>> templates (next format current classes) >>>>>> 2. Set the contents of license header file as the java >>>>>> file comment template in code templates section. >>>>>> >>>>>> Thanks, >>>>>> Kavith Lokuhewage >>>>>> >>>>>> [1] >>>>>> http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fruntime%2FIStatus.html >>>>>> [2] >>>>>> http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fruntime%2FPlatform.html >>>>>> [3] >>>>>> https://github.com/wso2/developer-studio/tree/master/plugins/org.wso2.developerstudio.eclipse.updater >>>>>> >>>>>> >>>>>> >>>>>> On Wed, May 11, 2016 at 9:25 AM, Nathiesha Maddage < >>>>>> nathieshamadd...@gmail.com> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I created a git hub repository, so the project progress can easily >>>>>>> be tracked. >>>>>>> >>>>>>> I could start up the plugin when the IDE starts up, by implementing >>>>>>> Istartup interface. I tested it as well. Then I created a log listener >>>>>>> class and attached that to the platform log, so any error is notified. >>>>>>> The next task is to filter the Dev studio plugin errors out of them. >>>>>>> For testing purposes, currently my code filters out the errors caused >>>>>>> by org.eclipse.core.runtime, and that seem to work fine. I created a >>>>>>> very >>>>>>> basic dialog to notify the error, which will be triggered when an error >>>>>>> occurs. I will further improve the UI later. >>>>>>> And currently I am working on collecting the information regarding >>>>>>> the error, that need to be included in the report. Certain information >>>>>>> like >>>>>>> plugin id, error message and severity can be easily obtained by the >>>>>>> Istatus >>>>>>> object, and now I am searching for ways to fetch the other information >>>>>>> like >>>>>>> java version, plugin version, osgi and bundle related information. >>>>>>> >>>>>>> GitHub Link- https://github.com/nathiesha/ErrorReportingTool.git >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Nathiesha >>>>>>> >>>>>>> On Thu, May 5, 2016 at 6:39 PM, Nathiesha Maddage < >>>>>>> nathieshamadd...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> This is the summary of the facts we discussed during the chat. >>>>>>>> >>>>>>>> >>>>>>>> - Original project proposal was discussed and it was confirmed >>>>>>>> that a new plugin would be developed for developer studio to report >>>>>>>> errors, >>>>>>>> that would have similar functionalities like code recommenders >>>>>>>> error >>>>>>>> reporting tool. >>>>>>>> >>>>>>>> >>>>>>>> - Certain suggestions were proposed for the original project >>>>>>>> proposal. >>>>>>>> >>>>>>>> >>>>>>>> 1. Instead of using an xml file to store user preferences, a >>>>>>>> separate preference page was suggested. >>>>>>>> 2. For a first time user, a dialog box to get the user input >>>>>>>> was suggested to be develop. The user given values for this dialog >>>>>>>> box >>>>>>>> would be stored in the preference page as well so that user can >>>>>>>> change >>>>>>>> those values later on using the preference page. >>>>>>>> 3. To get the information about the error and the error stack, >>>>>>>> the original idea was to read the log file and fetch the >>>>>>>> information. >>>>>>>> However it was suggested to make use the IStatus object instead, to >>>>>>>> get the >>>>>>>> error related data as it provided methods to fetch those data. >>>>>>>> 4. The plugin should only report the errors that is concerned >>>>>>>> with the developer studio. So as the first step, it was suggested >>>>>>>> to track >>>>>>>> all the errors caused by the developer studio plugin. This is to be >>>>>>>> implemented by listening to the error log of the dev studio plugin >>>>>>>> only. >>>>>>>> Once this task is accomplished, I was advised to implement a >>>>>>>> mechanism to >>>>>>>> filter all the other errors as well and find and any errors that >>>>>>>> has any >>>>>>>> connection with the developer studio and to report them as well. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - I had an issue about registering to the error event. That you >>>>>>>> clarified by suggesting to do the initialization in the start >>>>>>>> method of the >>>>>>>> BundleActivator implemented plugin class. And suggested me to try >>>>>>>> changing >>>>>>>> the start up behavior of the plugin from the default lazy >>>>>>>> initialization >>>>>>>> method into some different method in the manifest file of the >>>>>>>> plugin. >>>>>>>> >>>>>>>> >>>>>>>> - I was asked to get started with coding, and to maintain a >>>>>>>> git-hub repository, so you can view and comment on the parts I have >>>>>>>> done so >>>>>>>> far. >>>>>>>> >>>>>>>> >>>>>>>> - I was also asked to get started with the error capturing part >>>>>>>> first as it is of highest priority, and then to focus on the UI and >>>>>>>> connecting with Jira. >>>>>>>> >>>>>>>> >>>>>>>> - To track the progress of the project, a milestone plan was >>>>>>>> asked to be prepared on daily basis. >>>>>>>> >>>>>>>> >>>>>>>> - It was discussed to arrange the next meeting/call in another >>>>>>>> two weeks time. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please point out if I have missed any important fact in our >>>>>>>> discussion. >>>>>>>> I am currently preparing the milestone plan. I will send it soon. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Nathiesha >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Kavith Lokuhewage* >>>>>> Software Engineer >>>>>> WSO2 Inc. - http://wso2.com >>>>>> lean . enterprise . middleware >>>>>> Mobile - +9477-9-145-123 | +9471-455-6-401 >>>>>> Linkedin <http://www.linkedin.com/pub/kavith-lokuhewage/49/473/419> >>>>>> Twitter <https://twitter.com/KavithThiranga> >>>>>> >>>>> >>>>> >>>> >>>> Thanks, >>>> -- >>>> *Kavith Lokuhewage* >>>> Software Engineer >>>> WSO2 Inc. - http://wso2.com >>>> lean . enterprise . middleware >>>> Mobile - +9477-9-145-123 | +9471-455-6-401 >>>> Linkedin <http://www.linkedin.com/pub/kavith-lokuhewage/49/473/419> >>>> Twitter <https://twitter.com/KavithThiranga> >>>> >>> >>> >> >> >> -- >> >> *Jasintha Dasanayake* >> >> *Senior Software EngineerWSO2 Inc. | http://wso2.com >> <http://wso2.com/>lean . enterprise . middleware* >> >> >> *mobile :- 0711368118* >> >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > *Susinda Perera* > Software Engineer > B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL) > Mobile:(+94)716049075 > Blog: susinda.blogspot.com > WSO2 Inc. http://wso2.com/ > Tel : 94 11 214 5345 Fax :94 11 2145300 > >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
