Removal of singletons and other API changes, Groovy and otherwise

[Tim Fox]

Sparked off by feedback from Guillaume I have made a set of API
changes which affect the Java, JS, Ruby and Groovy apis.

The main things include

1) Vertx no longer uses singletons to get instances of objects like
Vertx, FileSystem, EventBus and SharedData. In fact singletons aren't
used anywhere any more, neither are static fields used to cache data.

Now you obtain an instance of Vertx then call methods on vertx to get
the various other objects.

If you're running in a container then a vertx instance will be
injected, otherwise if you're running embedded with Java or Groovy you
can create a vertx instance with Vertx.newVertx().

This should help with testing/mocking etc.

2) headers, params and trailers in the HTTP api are now maps

3) Bunch of other stuff

Anyway please take a look.

Groovy guys especially, please review again. I think we're pretty much
there now.

website docs still need to be updated. We can do that next week.

After which we can release another beta with the spanking new Groovy
api.

Happy Easter!

[Guillaume Laforge]

Hi Tim,

On Friday, April 6, 2012 2:06:37 PM UTC+2, Tim Fox wrote:

Sparked off by feedback from Guillaume I have made a set of API
changes which affect the Java, JS, Ruby and Groovy apis.

The main things include

1) Vertx no longer uses singletons to get instances of objects like
Vertx, FileSystem, EventBus and SharedData. In fact singletons aren't
used anywhere any more, neither are static fields used to cache data.

Now you obtain an instance of Vertx then call methods on vertx to get
the various other objects.

If you're running in a container then a vertx instance will be
injected, otherwise if you're running embedded with Java or Groovy you
can create a vertx instance with Vertx.newVertx().

This should help with testing/mocking etc.

This change is very welcome, in my opinion.

I'd probably go further and would like to see not just vertx being injected, but even eventBus, sharedData, and fileSystem injected too, the same way vertx is.

 

2) headers, params and trailers in the HTTP api are now maps

Cool :-)

 

3) Bunch of other stuff

Anyway please take a look.

Groovy guys especially, please review again. I think we're pretty much
there now.

I've attached a patch to this post, with a few minor changes:

- avoid using the script's binding when not really needed

- removed useless public keywords and semi-colons :-)

And that's essentially all.

I quite like how the API is looking like, from a usage perspective.

 

website docs still need to be updated. We can do that next week.

After which we can release another beta with the spanking new Groovy
api.

Woohoo :-)

 

Happy Easter!

You too, take care!

Guillaume 

[Guillaume Laforge]

And I forgot one change that I quite like: the usage of static imports.

Instead of Pump.createPump(a, b), you just need createPump(a, b) with the static import of that method.

[Guillaume Laforge]

One last thing...

There's a place where you're calling a private constructor of a class.

Currently, Groovy won't complain if you're doing this, but in future versions, it probably will, so better avoid it.

The Message class has a private constructor.

And in EventBus, in the wrapHandler() method, you're calling new Message()

You could perhaps make the Message constructor package-scope instead?

Guillaume

--
Guillaume Laforge
Groovy Project Manager
SpringSource, a division of VMware

Blog: http://glaforge.appspot.com/

Social: @glaforge / Google+

[Tim Fox]

On 06/04/2012 14:59, Guillaume Laforge wrote:

One last thing...

There's a place where you're calling a private constructor of a class.

Currently, Groovy won't complain if you're doing this, but in future versions, it probably will, so better avoid it.

The Message class has a private constructor.

And in EventBus, in the wrapHandler() method, you're calling new Message()

You could perhaps make the Message constructor package-scope instead?

Good catch, should be package scope. Message used to be an inner class of EventBus that's how the error crept in

[Tim Fox]

Cool :)

Any chance you could send a pull request? (Just being lazy)

[Johan Siebens]

Very nice update!

Small question though: any particular reason why FileSystem isn't an interface with a DefaultFileSystem implementation?

Maybe it's a good idea to see the FileSystem the same way as all the others (EventBus, HttpServer/HttpClient, ...)

And a Happy Easter to you too!

Johan

On Friday, April 6, 2012 2:06:37 PM UTC+2, Tim Fox wrote:

On Friday, April 6, 2012 2:06:37 PM UTC+2, Tim Fox wrote:

On Friday, April 6, 2012 2:06:37 PM UTC+2, Tim Fox wrote:

On Friday, April 6, 2012 2:06:37 PM UTC+2, Tim Fox wrote:

On Friday, April 6, 2012 2:06:37 PM UTC+2, Tim Fox wrote:

[Guillaume Laforge]

Yep, I'll try to create a pull request... but perhaps after the Easter break :-)

(my project isn't set up properly, so I think I need to clone it in github first instead of locally)

[Guillaume Laforge]

Pull request sent.

[Tim Fox]

Thanks :)

One small issue, compilation fails with:

  [groovyc] General error during semantic analysis: Can't use @PackageScope for method '<init>' which has explicit visibility.

  [groovyc] 

  [groovyc] java.lang.RuntimeException: Can't use @PackageScope for method '<init>' which has explicit visibility.

Doesn't seem to like that annotation on a constructor?

[Guillaume Laforge]

Remove it for now, I'll have a look at it next week.

Guillaume

[Tim Fox]

Hi Johan,

Yes, file system can be split into interface and impl too. 

Initially I tried to avoid a conventional Java style full-on intf/impl split since I think it's often overkill, however it looks like the project is moving in that direction.

However, some api classes need to remain as abstract classes since there are public members in the API, e.g. HttpServerRequest which has response, path, uri, etc. I think it's pretty ugly to have this as getters in Java.

If you like, you could make the change yourself and send me a pull request?

Cheers

[Johan Siebens]

Pull request sent.

I agree that it's often overkill to split everything into intf/impl, but if you look at the HttpServer/NetServer/EventBus... then it looks to me that the FileSystem can be handled the same way.

The same applies to SharedData as well. They can all be seen as some kind of internal component of the vertx system.

- Johan

[Tim Fox]

Merged it. Thanks Johan :)