incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <amccu...@gmail.com>
Subject Re: Blur Console v2 Design Proposal
Date Thu, 03 Oct 2013 18:16:19 GMT
For the Blur API relay I would suggest taking a look at a couple of classes.

If you use:
org.apache.blur.thrift.BlurClient

Iface iface = BlurClient.getClient("controller1:40010,...");

and then:

org.apache.blur.thrift.ThriftBlurShardServer line 257
 - context.addServlet(new ServletHolder(new TServlet(new
Blur.Processor<Blur.Iface>(iface), new TJSONProtocol.Factory())), "/blur");

This will add the servlet into a jetty server so that the "iface" variable
can answer requests.

I think this is all that's needed for the relay, assuming you have a jetty
server setup.

Aaron



On Wed, Oct 2, 2013 at 8:10 PM, Vikrant Navalgund <
vikrant.navalgund@gmail.com> wrote:

> +1 For proxying Blur API calls via a Jetty server and relaying back the
> data to the Client(Browser). With this approach we will have a clean
> separation of the Client and the Blur API.
>
> Please let me know how to begin with the tasks.
>
> Regards,
> Vikrant
>
>
> On Thu, Oct 3, 2013 at 1:26 AM, Chris Rohr <rohr.chris@gmail.com> wrote:
>
> > So as I have been getting into this more I am finding that using the
> > JavaScript API from the browser is not a good idea.  1. We will have to
> > deal with cross site scripting issues. 2. It will require the ENTIRE Blur
> > API to be exposed to browsers (potential security problem).  I think we
> > should just create calls in the Jetty Server that will make the calls to
> > Blur and return what is needed for the console.
> >
> > I want to get one call built into my branch then I will push it up so I
> can
> > get help. (Hopefully today)
> >
> > Thanks,
> > Chris
> >
> > On Tuesday, October 1, 2013, Chris Rohr wrote:
> >
> > > All,
> > >
> > > One thing I have found in looking at using the Javascript API is that
> we
> > > will need to make sure that the Blur Thrift server supports CORS
> > > (Cross-Origin Resource Sharing), this basically will allow us to get
> > around
> > > the Same-Domain policy since most of our browsers will not be on the
> Blur
> > > box itself.  Do any of you know if the server is setup with that turned
> > on?
> > >
> > > Thanks,
> > > Chris
> > >
> > >
> > > On Mon, Sep 30, 2013 at 8:38 PM, Vikrant Navalgund <
> > > vikrant.navalgund@gmail.com> wrote:
> > >
> > > Thank you Chris, that clears most of my doubts.
> > >
> > > Regards,
> > > Vikrant
> > > From: Chris Rohr
> > > Sent: 1/10/2013 2:29 AM
> > > To: blur-dev@incubator.apache.org
> > > Subject: Re: Blur Console v2 Design Proposal
> > > Vikrant,
> > >
> > > Thank you for your thoughts.  I will try to answer your questions here:
> > >
> > >    >>> What is this serving up? Is this a web service which would
be
> > > consumed by the AngularJS front end. Since you mentioned that it would
> > be a
> > > Jetty server(HTTP server + servlet container) a little clarification
> > would
> > > be great.
> > >
> > > In my initial thoughts, all the Jetty server would be used for is to
> > > provide an HTTP server and serve up the static html pages.  All of the
> > > dynamic nature of the console would be done through Javascript using
> > > AngluarJS and the JS Blur API.  However, in the future if there is a
> need
> > > for functionality that can't be done from the Browser directly (i.e.
> User
> > > logins, zookeeper status, etc) then we could setup some basic JSON web
> > > service calls that would be served up by Jetty.
> > >
> > >    >>> Are we going to pull the information from within the
> > > Browser(something like AJAX) or the Jetty server would do a query to
> the
> > > Thrift service and pass it back to the Browser.
> > >
> > > We will be trying to use the JS Blur API to access Blur directly,
> > however,
> > > we may run into Cross site scripting issues depending on how thrift
> works
> > > in JS and if that is the case then we would need to build proxies
> through
> > > the Jetty server.
> > >
> > >    >>> Since we will be using AngularJS and a Jetty server please
> clarify
> > > about not relying on a front-end and back-end component.  A typical
> > > scenario involving all the above 3 components would be helpful. This
> > would
> > > also help us in figuring out the options we have while selecting the
> > > technology.
> > >
> > > Currently the console contains 2 pieces of software, a Ruby on Rails
> > > application (front-end) and a Java application (back-end).  The Java
> > > application handles all of the information collection in Blur (i.e.
> > polling
> > > for statues, and tables, and queries) and stores everything in a
> > database.
> > > The Ruby on Rails application presents all of the data in GUI form.
>  The
> > > Ruby on Rails application does have some direct access to Blur, but
> does
> > > not have direct communication to the Java application.  This proposal
> > does
> > > away with the 2 separate pieces of code to 1. help simplify the logic
> and
> > > 2. help simply setup and startup of the console.
> > >
> > > I hope this answers your questions, please let me know if you think of
> > any
> > > more.
> > >
> > > Chris
> > >
> > >
> > > On Mon, Sep 30, 2013 at 2:38 AM, Vikrant Navalgund <
> > > vikrant.navalgund@gmail.com> wrote:
> > >
> > > > Hello Chris,
> > > > Thanks for the writeup.
> > > > As a developer interested in contributing to the new BLUR console I
> > have
> > > a
> > > > few questions.
> > > > Please ignore my lack of understanding of the architecture.
> > > > Treat me as a newbie to BLUR. My questions are inline.
> > > >
> > > >
> > > > On Mon, Sep 30, 2013 at 10:33 AM, Chris Rohr <rohr.chris@gmail.com>
> > > wrote:
> > > >
> > > > > All,
> > > > >
> > > > > As I have begun to start the next version of the console I wanted
> to
> > > give
> > > > > everyone my proposal for what should be in it and get any feedback
> > that
> > > > you
> > > > > may have.  I have created a new branch (new-blur-console) and will
> be
> > > > > pushing it up as soon as I can.  Please let me know if you have any
> > > > > questions/opinions/suggestions about this proposal.  If I don't
> hear
> > > from
> > > > > anyone, I will just assume it looks good and I will move forward.
> > > > >
> > > > > Thanks in advance,
> > > > > Chris
> > > > >
> > > > > *Blur Console v2 Design Proposal*
> > > > >
> > > > > *Purpose*
> > > > >
> > > > > This writeup will help to determine what direction the console
> > portion
> > > of
> > > > > Blur should go.  There has always been a need for a push button,
> easy
> > > > setup
> > > > > solution so that dev-ops could get up and running with the console
> > > > faster.
> > > > > *NOTE: *This is purely a suggestion and all opinions and
> > > recommendations
> > > > > are welcome.
> > > > >
> > > > >
> > > > > *Server*<
> > >
> > >
> >
>
>
>
> --
> *Regards*,
> *Vikrant Navalgund*
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message