Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Service code is broken when trying to use RubotoService directly #648

Closed
rscottm opened this Issue · 11 comments

2 participants

Scott Moyer Uwe Kubosch
Scott Moyer
Owner

I'm trying to bring Ruboto IRB in line with the latest Ruboto code. I'm noticing significant problems with the service code. We do have a service test, but it creates its own RubotoService subclass (avoiding the problems I'm seeing). I've got fixes for most of what is broken, but the trick is getting both use case working. The reason for this is the fact that onCreate is the typical entry method for Activities and it works for subclasses of RubotoService too (because you determine the script and class names from the subclass name). When you try to create a service from inside of Ruby (i.e., using RubotoService directly), the information about the class name is contained in the intent which is not known in onCreate. In those cases, we need to wait until onStartCommand to set up the remote delegate. Anyway, here's a list of some of the things I'm working on fixing:

  • When service.rb tries to create custom class name, it calls code (source_descriptor) that doesn't exist in service.rb (it is in activity.rb)
  • If you try to pass a :class_name into start_ruboto_service in a hash as the first argument, the information is ignored. The method defaults the options to {} and then only uses the hash in the first argument is nil
  • Still uses a global variable name (never sets it)
  • Requires class_name in the hash instead using it in the first argument like activity.rb
  • In general, it needs to follow the lead of activity.rb
  • On the Java side, the main issue is trying to set things up only in onCreate.
Scott Moyer
Owner

I should note the the current service.test_rb doesn't use/test service.rb.

Scott Moyer rscottm referenced this issue from a commit
Scott Moyer rscottm (#648) Added preOnStartCommand and preOnBind; condition preOnCreate t…
…o only function if not using RubotoService
92db191
Scott Moyer
Owner

I'll see if this revised test passes and then I'll create a few more tests.

Scott Moyer
Owner

Note: On services created directly from RubotoService: At the moment, I'm not calling onCreate in the script because the script isn't loaded until after onCreate. I'm sure we could, but I'm not sure how to avoid a second call to super.

Uwe Kubosch donv added this to the 1.1.3 milestone
Uwe Kubosch
Owner

Hi @rscottm !

How is this coming along? I'd like to push a release this weekend. We should support both use cases by then.

Scott Moyer
Owner

We support both cases now. The only question is whether we should call onCreate a "second" time for scripts that couldn't be loaded until onStartCommand. In that case:

1) onCreate is called. We can't open the script because there is not intent to specify the the script. We just call super.

2) onStartCommand is called. We can now load the script. Do we want to call onCreate in the ScriptingContainer now before we call onStartCommand?

Note 1: the one issue in calling it is that it will cause a second call to onCreate super.

Note 2: the one issue in not calling it is that it will not execute code that the developer puts into onCreate.

We're currently not calling onCreate the second time. It is a one line change to call it. I don't know if there are implications for Note 1.

Uwe Kubosch
Owner

The committed code does not load the script at all when using start_ruboto_service. The service_test fails. Do you have uncommitted code, @rscottm ?

Scott Moyer
Owner

My last checkin was a month ago:

Renamed service_test to service_gen_class_test to clarify the difference from other service tests

Perhaps I did it wrong. I was assuming that it would remove service_test when I renamed the file though git. That test is no longer supposed to be there. The tests seemed to pass at the time (718). Could the file have come back in through a subsequent checkin? Or did I just need to remove it explicitly?

Uwe Kubosch
Owner

OK, ee66058 only adds the new test, but was intended to remove the old. I'll remove the duplicate, but both fail currently along with ServiceBlockTest and ServiceClassTest. Are you able to run the tests successfully in your workspace?

Scott Moyer
Owner

I haven't run the tests on my machine in awhile. It's always just been easier to get things running and then monitor the Travis tests. That's what I don't understand. The tests worked when I submitted the code, and they've worked several times since then based on tests run after other code was checked in. The last set of services tests that failed seem to be due to a build failure. Therefore, I'm assuming the service tests work, and that we've got other problems that are causing the builds to fail.

Are they failing on your local run of the tests? I can try to get the tests running on my machine. I can't make any guarantees. I do my development in a VM and the tests take many hours and usually fail due to sone resource issue.

Uwe Kubosch
Owner

Looking at the travis build history, the service tests worked until very recently, long after your last commit, so it must be something else.

They are failing for me locally, so I'll investigate here.

I'll also see if I can get travis green by allowing known failures. That should help in detecting new errors.

Uwe Kubosch
Owner

I did a change in RubotoService to initialize JRuby if it was not already initialised.

Closing this issue since it seems it is solved.

Uwe Kubosch donv closed this
Uwe Kubosch donv added the bug label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.