Can you confirm you're on the master branch? I see "metron-streaming" in your path to RestTestingUtil and that was changed a LONG time ago. You're likely on a really old branch.
Ryan On Wed, Jun 28, 2017 at 3:27 PM, Vasco Yordanov <vasco...@yahoo.com.invalid> wrote: > Hello , I just forked from github and it seems that " Metron-Pcap_Service" > is failing with following errors: > > > [ERROR] /home/vasko/metron2/incubator-metron-fork/metron-streaming/ > Metron-Pcap_Service/src/main/java/org/apache/metron/ > pcapservice/RestTestingUtil.java:[212,5] cannot find symbol > [ERROR] symbol: class ResponseEntity > [ERROR] location: class org.apache.metron.pcapservice.RestTestingUtil > [ERROR] /home/vasko/metron2/incubator-metron-fork/metron-streaming/ > Metron-Pcap_Service/src/main/java/org/apache/metron/ > pcapservice/RestTestingUtil.java:[212,63] cannot find symbol > [ERROR] symbol: variable HttpMethod > [ERROR] location: class org.apache.metron.pcapservice.RestTestingUtil > > Please advise ? Before I start changing pom files ,I 'd like to run this > through you in case this is known issue. Thank you > From: merrimanr <g...@git.apache.org> > To: dev@metron.apache.org > Sent: Wednesday, June 28, 2017 4:05 PM > Subject: [GitHub] metron issue #620: Metron-988: UI for viewing alerts > generated by Metron > > Github user merrimanr commented on the issue: > > https://github.com/apache/metron/pull/620 > > Just tested again and I am able to now remove the first filter and > properly filter on values with special characters (referrer field for > example). I did another pass and found some trivial issues as well as a > few non-trivial issues and have made comments. > > I think more thought needs to be put into the AlertService.search and > AlertService.pollSearch functions. The AlertService.getAlert function is > very clear to me: it requires a couple of clearly named parameters and I > expect to get an 'Alert' type object back. The other functions in this > service are not as clear. The search function for example takes in a > QueryBuilder object which provides a generic javascript object as the body > for the post request. Then in return the post returns an Observable with a > generic javascript object. So essentially Typescript isn't being used here > when it should because it would make the search interface clearer. > > For example, I would prefer this function signature: > `public search(searchRequest: SearchRequest): > Observable<SearchResponse>` > > where SearchRequest and SearchResponse are model objects. The way it > is now it's not easy to understand what is being sent and what is expected > back unless you've spent time tracing the search calls to where requests > are built/response are processed and know all the source code well OR > already has a lot of experience with the ES query syntax. > > The result of all this is that not having a clear contract between the > search client/server will make developing a middle-tier more tedious. > > > --- > If your project is set up for it, you can reply to this email and have your > reply appear on GitHub as well. If your project does not have this feature > enabled and wishes so, or if the feature is enabled but not working, please > contact infrastructure at infrastruct...@apache.org or file a JIRA ticket > with INFRA. > --- > > >
