Custom Server and Build Problems

[Josh]

I know I mentioned a while ago that I was trying to get a custom server up and running in order to "inspect" the calls coming from the BITE extension. My goal was to eventually get a framework server in place that others could plug their own custom adapters into in order to work with different back-ends. FogBugz, JIRA, etc..

The project can be found here: https://github.com/jwcarroll/BITE-Server.net

Being a windows and .Net guy it is written in C# and ASP.Net MVC. It is far from complete at this point, but does allow you to inspect the calls in order to help expedite the building of "Adapters" to handle the calls.

Unfortunately I have had some strange issues when building the extension, and it doesn't seem to be functioning properly. Some of the calls show up (login, bugs/urls, getprojects), but that is where the functionality starts to flake out. My guess is that the extension is not building properly, but I have no real way to know for sure.

The behavior I see during a build is that when it gets to actually running the Closure Compiler, dozens of Java instances open up on my machine. Eventually one or two of them hang up and just sit there. If I close one of them, then another dozen or so Java processes (windows) open up and eventually one or two of them lock up again. I'm sure this is not a good thing. The result is that I'm not sure what state the extension is actually in. All I know is that it only half works.

Anyway... I still feel like this is such an awesome concept that it needs to be opened up to as many people as possible (hence the custom server), but I just can't seem to really get off the ground. I'm sure there is something I am doing wrong, but I just can't figure out what it is.

p.s. If anybody is interested in how the custom server works, or wants to help build it out, let me know.

[Jason Stredwick]

Hi Josh,

The build system is somewhat flaky as it was developed quickly and on
Linux only. I spent some time to get it cross-platform and that
worked to some degree. In version you are using, if the closure
compiler failed to compile a file the build system would still create
an empty version of the compiled file; and thus a bad extension.
Since, the build doesn't track dependency changes there was no way to
know unless you checked manually.

Recently, I rewrote the build system to hopefully make it easier to
understand where problems arise and prohibit the building of the
extension in a bad state. In this version, it prints out more
information and as it compiles it tells you who it is building and
when it is done instead of an unconnected blob of data. If one of the
files fails to compile it will then kill all the other compile
processes and clean up their files. Also, since you are a Windows
user, I noticed that Windows does not work well at all with the multi-
process compile. To that end, I now detect if you are on Windows and
force it to compile each file one at a time.

Please try out my new build. To do this, you will need to remove your
dependencies first with build.py --expunge. Then running build again
should download the correct stuff.

I am glad you are still excited even after all the hurdles. Please by
all means ask questions or for changes and I will help and fix as I
have time available.

Jason

> *p.s. *If anybody is interested in how the custom server works, or wants to

[Josh Carroll]

Is the new build you mentioned the separate repository I noticed [build]. Also, is it compatible with what is in the Master branch, or do I need to move over to the Dev branch?

--
Josh Carroll

jwarren...@gmail.com

865.603.0598

[Jason Stredwick]

Yes, it appears that it is only in dev. I am a little reluctant to
update master at the moment just because I don't have time to update
the running versions. I may have time next week to update master, but
then it would be identical to dev.

For the build, I did create a new repo, but you don't need to clone
it. If you use the dev version of BITE it will automatically pull
down the build as a dependency (that is one reason you need expunge).
Also, make sure you are using 2.7 (or potentially 3+) or you will need
to download argparse.py. It will tell you when you build if you need
it.

Please let me know if you have issues. I tested it on Windows XP.

Jason

On Apr 26, 10:41 am, Josh Carroll <jwarren.carr...@gmail.com> wrote:
> Is the new build you mentioned the separate repository I noticed [build].
> Also, is it compatible with what is in the Master branch, or do I need to
> move over to the Dev branch?
>

> On Thu, Apr 26, 2012 at 12:38 PM, Jason Stredwick <jason.stredw...@gmail.com

> jwarren.carr...@gmail.com
> 865.603.0598

[Josh]

Ok, so hopefully you aren't sick of me yet :)

The new build appears to work beautifully and ran just fine. I fired up my inspector, and saw the "check_login_status" request come in, but the extension seems to think I am not logged.

Here is the response I am sending back from the server:

HTTP/1.1 200 OK

Server: ASP.NET Development Server/10.0.0.0

Date: Thu, 26 Apr 2012 20:44:13 GMT

X-AspNet-Version: 4.0.30319

Cache-Control: private

Content-Type: application/json; charset=utf-8

Content-Length: 70

Connection: Close

{"loggedIn":true,"user":"jcarroll","url":"http://www.myUrl.com/login"}

However, it is quite clear that the login is failing as I can pop open the Chrome developer tools and see the failure written to the console:

Has the expected shape of the JSON changed at all in the DEV branch?

[Jason Stredwick]

No worries, these are the kinds of issues that need to be worked out
sooner rather than later.

I don't think anything has changed for login. I just checked and
loginmanager.js doesn't look like it has changed since January.

How do you handle login? Do you have your own backend server (not
just a proxy)? Or do you also use AppEngine too?

I will be honest that I don't remember the JSON for login, but should
the boolean value for loggedIn be quoted?

Jason

On Apr 26, 1:52 pm, Josh <jwarren.carr...@gmail.com> wrote:
> Ok, so hopefully you aren't sick of me yet :)
>
> The new build appears to work beautifully and ran just fine. I fired up my
> inspector, and saw the "check_login_status" request come in, but the
> extension seems to think I am not logged.
>
> Here is the response I am sending back from the server:
>
> HTTP/1.1 200 OK
> Server: ASP.NET Development Server/10.0.0.0
> Date: Thu, 26 Apr 2012 20:44:13 GMT
> X-AspNet-Version: 4.0.30319
> Cache-Control: private
> Content-Type: application/json; charset=utf-8
> Content-Length: 70
> Connection: Close
>
> {"loggedIn":true,"user":"jcarroll","url":"http://www.myUrl.com/login"}
>
> However, it is quite clear that the login is failing as I can pop open the
> Chrome developer tools and see the failure written to the console:
>

> <https://lh3.googleusercontent.com/-_s-7wxxHA_A/T5m1F27isRI/AAAAAAAABO...>

[Josh]

The server I have right now is literally just a shell. I am stubbing out responses to learn about BITE so I can later go back and fill it in with a real set of adapters. The grand idea is a .Net server implementation that will allow you to "plugin" new adapters by simply dropping the .dll's in the bin folder.

The server is designed to handle all incoming requests and map the calls to the underlying adapter code via convention.

So... right now that is just a hard coded response.

As far as the JSON coming back, I'm pretty sure that boolean values aren't required to be quoted.

Any other thoughts on a better way to debug? Chrome extensions aren't really my forte, so I'm a bit of a duck out of water trying to figure out where things went wrong on that side. I guess I need to get up to speed rather than hit you up every time I have a problem ;)

-- Josh

[Jason Stredwick]

Cool, that is what I suspected just wanted to make sure that is the
server you were building.

I just brought up the extension background and checked the network
communication.  It looks like the response is in the format you
expected:

{"url": "https://bite-playground-dev.appspot.com/_ah/logout?
continue=https://www.google.com/accounts/Logout%3Fcontinue%3Dhttps://
appengine.google.com/_ah/logout%253Fcontinue%253Dhttps://bite-
playground-dev.appspot.com/%26service%3Dah", "loggedIn": true, "user":
"jason.s...@gmail.com"}

Looks what you return essentially.

Feel free to ping me over chat if you want.  May be faster to narrow
it down quicker.  As long as we post the final solution.  I have
another 1.75 hours left today, otherwise tomorrow.

[Josh Carroll]

Probably won't get a chance to look again until tonight, so I will bang around on it some and let you know how it goes.

[Jason Stredwick]

Cool, that is what I suspected just wanted to make sure that is the
server you were building.

I just brought up the extension background and checked the network
communication.  It looks like the response is in the format you
expected:

{"url": "https://bite-playground-dev.appspot.com/_ah/logout?
continue=https://www.google.com/accounts/Logout%3Fcontinue%3Dhttps://
appengine.google.com/_ah/logout%253Fcontinue%253Dhttps://bite-
playground-dev.appspot.com/%26service%3Dah", "loggedIn": true, "user":
"jason.s...@gmail.com"}

Looks what you return essentially.

Feel free to ping me over chat if you want.  May be faster to narrow
it down quicker.  As long as we post the final solution.  I have
another 1.75 hours left today, otherwise tomorrow.



On Apr 26, 2:11 pm, Josh <jwarren.carr...@gmail.com> wrote:

[Jason Stredwick]

Were you ever able to resolve your problem?

Po recently found a couple issues with some of my recent changes.

1. The server was missing an external dependency (got chopped by
accident)
2. For some reason, there were about 8 locations in the code where the
use of

bite.common.net.xhr.async.get and post

response handlers were not updated to the new code. This includes
loginmanager.js. This means that calls to the server were causing the
JSON.parse(data) to throw and exception as data is undefined.

If you get a chance, please sync your code and give it another shot.
Sorry that I didn't pick up on this earlier. I saw we were getting
the same results from the server. I didn't think the issue was
processing those results.

Jason

On Apr 26, 3:19 pm, Jason Stredwick <jason.stredw...@gmail.com> wrote:
> Cool, that is what I suspected just wanted to make sure that is the
> server you were building.
>
> I just brought up the extension background and checked the network
> communication.  It looks like the response is in the format you
> expected:
>
> {"url": "https://bite-playground-dev.appspot.com/_ah/logout?
> continue=https://www.google.com/accounts/Logout%3Fcontinue%3Dhttps://
> appengine.google.com/_ah/logout%253Fcontinue%253Dhttps://bite-
> playground-dev.appspot.com/%26service%3Dah", "loggedIn": true, "user":

> "jason.stredw...@gmail.com"}