Volunteers required for Vert.x 3.0 development

[Tim Fox]

Hello folks. I've created a project plan for Vert.x 3.0:

https://drive.google.com/file/d/0B4J2ye6tk2EhTmdBM3ltLVd0eE0/edit?usp=sharing

You can view it using https://stackedit.io (follow the links from the drive url to install)

Tasks are broken down roughly into:

1. Core development - this is stuff that we need to do in the main project

2. "ext" development (extensions). This is stuff that's not core, but will form part of the "stack" that we're going to provide for Vert.x 3.0 application developers.

ext verticles will provide functionality such as database access, IoT services, email and many other things that are commonly wanted when writing Vert.x apps. 

3. Various other things like writing docs, new web site etc.

At this stage, progress has been progressing well on core - most of the Vert.x 3.0 core is complete and we have code generation working now - I already have the generated JavaScript API almost complete and codegen can also be used to generate idiomatic other language APIs for any compliant interface (more on this is another email).

We're now looking to get the community involved in the rest of the development. 

A lot of the remaining work will be in getting the "ext" verticles done. At lot of these won't be written from scratch but can be ported from the Vert.x 2.x versions (e.g. MongoDB module, JDBC module, etc). If you've already been involved in the Vert.x 2 equivalent I would love you to continue helping with the Vert.x 3 versions.

There is also some core work to be done if that is more your bag.

So.. if you're interested in helping you can reply on this thread (or email me privately if you are shy ;) ), and we can hopefully find something appropriate for you (based on your skills, interests and how much time you have to spare).

[Sridhar Jonnalagadda]

I can help for contributing to 3.0. Looked at task list. I can start contributing to core and then move onto ext part. I have implemented couple of projects using Vertx framework.

[Paulo Lopes]

For stomp I've an async module that has been tested with activeMQ and RabbitMQ, i am open to give it to the ext as I did for the redis module:

https://github.com/pmlopes/mod-stomp-io

maybe some work can be done there to provide a fluent API like there is for redis.

[Tim Fox]

STOMP is not currently on the list for Vert.x 3.0 ext, but it would be nice to have it in the community for Vert.x 3.0.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Fox]

BTW still waiting for your suggestions on improvements to the Java Json API for Vert.x 3.0, otherwise it will stay the same ;)

On 21/07/14 16:20, Paulo Lopes wrote:

--

[Paulo Lopes]

for point 18) web frameworks

Yoke has been in development since vert.x 1.3.1 days, I've been using it in real big projects, but mostly it goes with my taste in what regards APIs, features since I am the mainly developer although i just got a huge contribution to the JS bindings.

I would love to see yoke as a framework endorsed by the vert.x community and lets talk about what is it doing wrong/right how can we make it better... I sure will need lots of help to get it to work on vert.x 3.x if there are big API changes :)

In what regards to to project itself, i've been splitting core middleware from extras and already isolated render engines into single addons, and also utility middleware such as swagger documentation generator, JMX, etc...

In a nutshell yoke has:

* middleware manager
* security module based on java keystores (no plain text passwords)
* static file serving with appropriate caching headers
* cookies manager
* session managers in memory, redis or mongodb
* method override
* error handing
* JWT tokens processing
* routing with param handing
* annotation based router (for java and groovy)
* basic REST API support with router and validators

render engines:

* java string place holder replacer
* jade
* handlebars
* groovy template
* js ejs
* mvel
* thymeleaf

extra middleware:

* helmet webapp security
* rest store (make rest endpoints from mongodb collections, or other data source)
* swagger documentation and api testing

And lots of other things i did not mention  :)

@Tim what can I do to make vert.x 3 even better :)

[Jared Holdcroft]

Hey Tim,

I've got tons of experience with Java and Ruby and would love to help out with some core work. I'm freelance so reasonably flexible and could probably put 5-10 hours a week in depending on other projects.

Cheers,

jared.

[Paulo Lopes]

about the json API i can take in on my plate.

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/0p-fx926g6o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Paulo Lopes
www.jetdrone.com

[Fernando Jordán Silva]

Hi Tim

I'd like to help with the native iOS implementation. I have a lot of experience work info with Vert.x and iOS

[Fernando Jordán Silva]

I forgot to mention: I have developed a module for Push notificacions (Vert.x 2.x) to send messages to iOS, Android and (under development) Windows Phone.

Are you interested in a port to Vert.x 3 of this module?

[Tim Yates]

I'll have a go at kicking a general JDBC extension into shape in my spare time

Is there a provision for signing the cla where I promise to only work on it during the hours of "getting the kids to bed" and "getting myself to bed"?

--

[Tim Yates]

Of course I meant "between", not "during"... 🙀

[Rick Hight]

Timeline?

[Tim Yates]

Out of interest, are there any magical invocations I need to be making to get the blocking JDBC API playing nicely with the eventBus (ala multithreaded:true and worker: true)?

[Manuel Jesús Recena Soto]

Hello Tim,

I would like to help on this issues:

1) Continuous Integration: automatization of tasks (package, binary
distribution, tests, etc)
2) Source Code Inspection: metrics

I can offer to Vertx project a FREE ClinkerHQ Cloud [1] instance.

Regards,

[1] http://clinkerhq.com

> --
> You received this message because you are subscribed to the Google Groups
> "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vertx+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Manuel Jesús Recena Soto
Founder, CEO & CTO of klicap - ingeniería del puzle

mobile phone +34 664 000 629
work phone + 34 954 894 322
www.klicap.es | blog.klicap.es

[Stephan Wissel]

I started looking at the mongo driver and port it to CouchDB. I'd like to make it as signature compatible to the mongo driver as possible.

[Sridhar Jonnalagadda]

What is the process for picking a task and contribute?

On Monday, 21 July 2014 06:47:28 UTC-4, Tim Fox wrote:

[Sridhar Jonnalagadda]

Can we use JDK 1.8 lambda feature for 3.0?

On Monday, 21 July 2014 06:47:28 UTC-4, Tim Fox wrote:

[Giovanni Baleani]

I can contribute with my module for MQTT (https://github.com/giovibal/vertx-mqtt-broker-mod) it's quite stable, supports Qos 0,1,2 and i'm working on websocket transport.
There's no problem if you would insert it in "Ext development / IoT" modules.

[Tim Fox]

On 21/07/14 15:53, Sridhar Jonnalagadda wrote:

I can help for contributing to 3.0. Looked at task list. I can start contributing to core and then move onto ext part. I have implemented couple of projects using Vertx framework.

Awesome - please send me an email timvolpe at gmail.com and I can get you something easy to start off with :)

--

[Tim Fox]

I would certainly love to see this ported to Vert.x 3.0 :)

--

[Tim Fox]

On 21/07/14 17:44, Paulo Lopes wrote:

about the json API i can take in on my plate.

Ok Great :)

(I'm looking at this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=438701 )

How about submitting a PR against Vert.x 3.0 codebase?

[Tim Fox]

On 21/07/14 18:06, Fernando Jordán Silva wrote:

Hi Tim

I'd like to help with the native iOS implementation. I have a lot of experience work info with Vert.x and iOS

Great! Basically I was thinking of a native IoS client which can talk to the Vert.x event bus.

Also.. have a look at these:

https://github.com/goodow/realtime-channel

https://github.com/goodow/realtime-android

[Tim Fox]

On 21/07/14 18:09, Fernando Jordán Silva wrote:
> I forgot to mention: I have developed a module for Push notificacions (Vert.x 2.x) to send messages to iOS, Android and (under development) Windows Phone.

Also awesome

>
> Are you interested in a port to Vert.x 3 of this module?

Yes, would be interested in this. Have you got a pointer to the repo?

[Tim Fox]

Great, send me an email timvolpe at gmail.com and can get you a task :)

--

[Tim Fox]

On 21/07/14 18:32, Tim Yates wrote:

I'll have a go at kicking a general JDBC extension into shape in my spare time

I know you wouldn't disappoint, Tim :)

Is there a provision for signing the cla where I promise to only work on it during the hours of "getting the kids to bed" and "getting myself to bed"?

I can ask the Eclipse lawyers to draft you an individual one if you like? ;)

[Tim Fox]

On 21/07/14 21:11, Tim Yates wrote:

Out of interest, are there any magical invocations I need to be making to get the blocking JDBC API playing nicely with the eventBus (ala multithreaded:true and worker: true)?

Yes, I think it needs to be multi-threaded and worker.

However Vert.x can do some nice magic that Vert.x 2.0 can't.

If you define a nice rich API for accessing the data, e.g. a kind of asynchronous JDBC, something like (off the top of my head)

interface AsyncJDBC {

   void executeQuery(String sql, Handler<AsyncResult<ResultSet>> resultHandler);

}

Then Vert.x can do the magic to make sure that API is usable as a proxy from a completely different verticle, so you you don't have to fiddle about sending messages directly on the event bus, you can use a much more intuitive api.

[Tim Fox]

Good question.

It's a very rough estimate, but I think we're aiming for final at the end of the year, but would hope to get some alphas and betas out well before that.

On 21/07/14 19:47, Rick Hight wrote:

Timeline? --

[Tim Fox]

Sounds good

On 22/07/14 02:08, Stephan Wissel wrote:

I started looking at the mongo driver and port it to CouchDB. I'd like to make it as signature compatible to the mongo driver as possible.

[Tim Fox]

Mail me at timvolpe at gmail.com :)

--

[Tim Fox]

Yes, Vert.x 3.0 is Java 8 only :)

--

[Tim Fox]

Excellent, this would be great :)

[Tim Fox]

One thing I should add - if you're interested in working on core, if you start by submitting a full pull requests and everything is turning out well, then we can consider getting you voted in as proper Eclipse committers to the project (which means you can work directly on core) - this would be good as we need more non Red Hat committers on the main project :)

[Simone Scarduzio]

Tim, about Elasticsearch: what do you have in mind as an "ext" project about it? 

Everybody (included massive users like Stack Exchange) now connects to Elasticsearch through its embedded Netty based REST API.

In my opinion this means that we already have an Elasticsearch connector. And it's called HttpClient :)

Right?

-Simone

[Tim Fox]

I was thinking along the lines of https://github.com/englishtown/vertx-mod-elasticsearch so you could interact with it over the event bus, not REST

[Adrian Gonzalez]

Tim, I have a few modules that I'd be happy to move under vert.x extensions if there is interest:

vertx-mod-elasticsearch (https://github.com/englishtown/vertx-mod-elasticsearch)

Java specific:

vertx-mod-jersey (https://github.com/englishtown/vertx-mod-jersey)

vertx-mod-hk2 (https://github.com/englishtown/vertx-mod-hk2)

vertx-mod-guice (https://github.com/englishtown/vertx-mod-guice)

vertx-mod-cassandra (https://github.com/englishtown/vertx-mod-cassandra)

[Hartog De Mik]

I would suggest to wrap the REST interface in the elasticsearch module and make the transport layer configurable. Not everybody has the luxury of connecting to the java-transport interface of ES and are forced to use the REST api. 

[Hartog C. de Mik]

On Tue, Jul 22, 2014 at 03:46:47PM +0100, Tim Fox wrote:
> I was thinking along the lines of
> https://github.com/englishtown/vertx-mod-elasticsearch so you could
> interact with it over the event bus, not REST

I would suggest offering both solutions, and wrapping a REST client to
provide an EventBus API so that elasticsearch remains an easily available
option when the transportlayer is not available to you (network
restrictions, hosted elasticsearch, etc.)

I am facing that problem right now... Perhaps the englishtown module can be
extended in such a manner that the method of transport is configurable.


Kind regards,
Wish I could contribute more, :'(
Hartog de Mik

> >> send an email to vertx+un...@googlegroups.com <javascript:>.

> >> For more options, visit https://groups.google.com/d/optout

> >> <https://groups.google.com/d/optout>.

> >
> >--
> >You received this message because you are subscribed to the Google
> >Groups "vert.x" group.
> >To unsubscribe from this group and stop receiving emails from it,
> >send an email to vertx+un...@googlegroups.com

> ><mailto:vertx+un...@googlegroups.com>.

[Tim Fox]

Why not just use the httpClient to access it?

[Kenichiro Murata]

Hi Tim.

I'd like to help with No.8 Docker.

I've created a dockerfile for vertx project.

https://github.com/muraken720/docker-vertx

Regards,

Kenichiro Murata.

2014年7月21日月曜日 19時47分28秒 UTC+9 Tim Fox:

Hello folks. I've created a project plan for Vert.x 3.0:

https://drive.google.com/file/d/0B4J2ye6tk2EhTmdBM3ltLVd0eE0/edit?usp=sharing

[Yatindra AP]

I can help out in 4.2 Groovy and 10 Auth module.

BTW would a lang mod for groovy be still required if Vert.x 3.0 is Java 8 only.

[Tim Yates]

Groovy is much more than lambdas

--

[Yatindra AP]

Agreed. Was just asking because groovy now transparently coerces Clousures to functional interfaces and abstract classes.

I only saw few instances of leftShit overloading and changing method names to Java bean style getters and setters in the current (2.1) version.

Rest everything seemed to be decorations for closure to handler coercion.

With that burden gone, can't the rest be handled with runtime traits or mixin just after classloading/instantiation?

[Tim Fox]

On 23/07/14 21:55, Yatindra AP wrote:

Agreed. Was just asking because groovy now transparently coerces Clousures to functional interfaces and abstract classes.

I only saw few instances of leftShit overloading and changing method names to Java bean style getters and setters in the current (2.1) version.

Rest everything seemed to be decorations for closure to handler coercion.

With that burden gone, can't the rest be handled with runtime traits or mixin just after classloading/instantiation?

Julien is doing the Groovy API as we speak - perhaps he can comment on that.

[Stephan Wissel]

I presume you are writing the MongoDB driver?
What are the methods and their signatures you are planning?
Same like 2.x or something new?

[Julien Viet]

I have been working on the code generation project for Groovy. It is quite alpha/beta status but now it generates a Groovy API that compiles and the implementation can run a simple http server example.

Concerning the specific Groovy features:
- it uses map/list for configuration (as in 2.x)
- it does not use the Closure type and stick with functional interfaces

From the implementation perspective the focus is on the groovy/java object wrapping/unwrapping work correctly and after on the Groovy specific parts.

For feedbacks/contributions the current repository is here: https://github.com/vietj/vertx-groovy . Note that you should at least compile the project to see the full Groovy API generated by codegen.

--
Julien Viet
www.julienviet.com

[Sharat Koya]

Hi, I am interested - I saw your talk at Qcon - will be happy to help with documentation, though I am not allowed to develop code under my existing contract.

[Jamie B]

Hi Tim - I would like to help in some way.  Maybe docs or marketing.  I've prototyped a couple projects with Vert.x.  Probably don't have time/expertise to commit code, but would love to help and see Vert.x 3 really kick ass in the market.  

-jamie  

[Hadi Hariri]

Hey Paulo,

What's the status for Yokes and 3.0? Need any help? I've worked on an HTTP framework based on Connect that uses Netty (https://github.com/hhariri/wasabi), but would be nice to get some of that same functionality in to Vertx modules. I see Yoke has some of this already.

On Monday, July 21, 2014 5:33:18 PM UTC+2, Paulo Lopes wrote:

for point 18) web frameworks

Yoke has been in development since vert.x 1.3.1 days, I've been using it in real big projects, but mostly it goes with my taste in what regards APIs, features since I am the mainly developer although i just got a huge contribution to the JS bindings.

I would love to see yoke as a framework endorsed by the vert.x community and lets talk about what is it doing wrong/right how can we make it better... I sure will need lots of help to get it to work on vert.x 3.x if there are big API changes :)

In what regards to to project itself, i've been splitting core middleware from extras and already isolated render engines into single addons, and also utility middleware such as swagger documentation generator, JMX, etc...

In a nutshell yoke has:

* middleware manager
* security module based on java keystores (no plain text passwords)
* static file serving with appropriate caching headers
* cookies manager
* session managers in memory, redis or mongodb
* method override
* error handing
* JWT tokens processing
* routing with param handing
* annotation based router (for java and groovy)
* basic REST API support with router and validators

render engines:

* java string place holder replacer
* jade
* handlebars
* groovy template
* js ejs
* mvel
* thymeleaf

extra middleware:

* helmet webapp security
* rest store (make rest endpoints from mongodb collections, or other data source)
* swagger documentation and api testing

And lots of other things i did not mention  :)

@Tim what can I do to make vert.x 3 even better :)



On Monday, July 21, 2014 5:20:17 PM UTC+2, Paulo Lopes wrote:

For stomp I've an async module that has been tested with activeMQ and RabbitMQ, i am open to give it to the ext as I did for the redis module:

https://github.com/pmlopes/mod-stomp-io

maybe some work can be done there to provide a fluent API like there is for redis.

On Monday, July 21, 2014 4:53:56 PM UTC+2, Sridhar Jonnalagadda wrote:

I can help for contributing to 3.0. Looked at task list. I can start contributing to core and then move onto ext part. I have implemented couple of projects using Vertx framework.

[Maziz Esa]

Hi Tim,

Need help for Android Native event bus client or Push notification for GCM? or anything related with Android?

Regards,

Maziz.

[Julien Viet]

Hi Maziz,

for sure your help will be appreciated on android bative event bus client or the GCM push notifs.

perhaps you can start to look at android event bus client ?

--
Julien Viet
www.julienviet.com

[Arne N]

Hi, I would love to contribute to this awesome project! I have experience in Java and some in Frontend-developement. I am working on my first Vertx-project for a couple months now. Tell me what to do and I will be happy to help.  

[Julien Viet]

Hi Arne,

you can look at the 3.0 Plan and find a task:

https://drive.google.com/file/d/0B4J2ye6tk2EhTmdBM3ltLVd0eE0/edit?usp=sharing

You can view it using https://stackedit.io (follow the links from the drive url to install)

if you have doubts about a feature don’t hesitate to ask here or on IRC.

--
Julien Viet
www.julienviet.com

[Tim Yates]

Is there an example repo for each type of module?  (worker, multithreaded, etc)?

[Julien Viet]

what do you mean exactly ?

I’ve been working on a new example repo for 3 that consumes Vert.x core and Vert.x ext APIS in Groovy and JS : https://github.com/vert-x3/vertx-examples

--
Julien Viet
www.julienviet.com

[Tim Yates]

Cool, I'd not seen that! :-D

I was wondering for the JDBC module, I believe I would need to declare it as multithreaded somewhere as with the 

"multi-threaded": true, "worker": true, I had in the v2 mod

[Nick Scavelli]

Yea so this is an interesting question since verticle deployment is really the responsibility of the developer now. Meaning it's done programatically and not dictated by mod.json. 

So currently there is nothing really preventing someone from deploying the jdbc verticle as a normal event-loop verticle. We might want to make a WorkerVerticle interface so we can reduce this issue ?

[Julien Viet]

perhaps a Verticle to provide default options object initialized with the correct default config somewhere in the verticle codebase that the user can copy when creating it ?

--
Julien Viet
www.julienviet.com

On 27 Aug 2014 at 17:17:47, Nick Scavelli (nick.s...@gmail.com) wrote:
> Yea so this is an interesting question since verticle deployment is really
> the responsibility of the developer now. Meaning it's done programatically
> and not dictated by mod.json.
>
> So currently there is nothing really preventing someone from deploying the
> jdbc verticle as a normal event-loop verticle. We might want to make a
> WorkerVerticle interface so we can reduce this issue ?
>
> On Wednesday, August 27, 2014 11:04:37 AM UTC-4, Tim Yates wrote:
> >
> > Cool, I'd not seen that! :-D
> >
> > I was wondering for the JDBC module, I believe I would need to declare it
> > as multithreaded somewhere as with the
> >
> > "multi-threaded": true, "worker": true, I had in the v2 mod
> >
> >
> > On 27 August 2014 15:57, Julien Viet >

[Julien Viet]

That being said, I’m working at the moment on “Options model” in codegen, to allow proper Options inheritance among all.

I believe Verticle should provide their own typed options that inherits from DeploymentOptions class the the user would use. Such verticle deployment options could provide convenient default value for those. For instance:

@Options
interface JdbcDeploymentOptions extends DeploymentOptions {
  void setDriverClassName(String driverClassName);  
  // etc...
}

Those options would then be marshalled in the DeploymentOptions#config field (at least at the beginning)

--
Julien Viet
www.julienviet.com

[Arne N]

 I don't know if I understad task 13 ("Look at Lazybones, Jhipster, yeoman etc for generating Vert.x projects") correctly. Are you suggesting suggesting to write a yeoman-generator for Vert.x? 

If so, what should be generated by it? Something like the Gradle-Template? 

I have some experience using Yeoman and I like this tool a lot, but never wrote a generator myself. But nonetheless, I would certainly give it a try :)

[Tim Fox]

Maybe can build on this? :

https://github.com/goodow/realtime-android

https://github.com/eclipse/vert.x/wiki/Useful-Vert.x-components-and-modules

On 21/08/14 10:25, Julien Viet wrote:

[Oliver Rolle]

In vertx3 the module system seems to be history. How can I encapsulate functionality and distribute the code on many servers?

[Julien Viet]

Hi Olivier,

verticle factory have more freedom and don’t have to to operate on a local file but on an “id” that it can interpret as it like, like I did in this POC that deploys modules stored in maven repository: https://github.com/vietj/vertx-maven-modules

--
Julien Viet
www.julienviet.com

On 1 Sep 2014 at 14:04:27, Oliver Rolle (oliver...@googlemail.com) wrote:
> In vertx3 the module system seems to be history. How can I encapsulate
> functionality and distribute the code on many servers?
>

[Oliver Rolle]

so maven will resolve dependencies? Cool stuff!

[Tim Fox]

On 01/09/14 13:04, Oliver Rolle wrote:

In vertx3 the module system seems to be history. How can I encapsulate functionality

In Vert.x 3.0 your "modules" are just jars that you can put in Maven like any other jar. Dependencies are resolved at build time in the standard Maven way.

and distribute the code on many servers?

[Oliver Rolle]

Hi Tim,

I like to write module registry for vertx & vertigo which can be crawled by search engines, provides a REST api to other applications and updates itself by automatically crawling maven repositories. This registry allows to find modules (faster) and allows vertigo to be programmed visually, by providing a searchable list of modules (nodes) and module communication interfaces (edges) which can than connected to a processing / application network. The network itself is a module which can be shared over the registry (or maven) adding more functionality to vertigo. The concept behind all this is (in practice proven) flow based programming paradigm [1].

(1) Is there a way to find vertx3 jars in maven central automatically? In vertx2 I need to search for "mod.zip" [2] to get an extensive list.
(2) Do these jars contain a mod.json similar to vertx2, which contains verbose information about the module?

Best regards
Oliver

[1]: http://en.wikipedia.org/wiki/Flow-based_programming
[2]: http://search.maven.org/#api

[Paolo Ucchino]

I found vertx-mod-cassandra really interesting, i hope you'll port it under Vertx 3.0 asap!

Best regards

Il giorno martedì 22 luglio 2014 22:00:21 UTC+2, Adrian Gonzalez ha scritto:

Tim, I have a few modules that I'd be happy to move under vert.x extensions if there is interest:

vertx-mod-elasticsearch (https://github.com/englishtown/vertx-mod-elasticsearch)

Java specific:

vertx-mod-jersey (https://github.com/englishtown/vertx-mod-jersey)

vertx-mod-hk2 (https://github.com/englishtown/vertx-mod-hk2)

vertx-mod-guice (https://github.com/englishtown/vertx-mod-guice)

vertx-mod-cassandra (https://github.com/englishtown/vertx-mod-cassandra)

On Tuesday, July 22, 2014 10:46:51 AM UTC-4, Tim Fox wrote:

I was thinking along the lines of https://github.com/englishtown/vertx-mod-elasticsearch so you could interact with it over the event bus, not REST

On 22/07/14 14:45, Simone Scarduzio wrote:

Tim, about Elasticsearch: what do you have in mind as an "ext" project about it? 

Everybody (included massive users like Stack Exchange) now connects to Elasticsearch through its embedded Netty based REST API.

In my opinion this means that we already have an Elasticsearch connector. And it's called HttpClient :)

Right?

-Simone

On Tuesday, July 22, 2014 12:20:10 PM UTC+1, Tim Fox wrote:

One thing I should add - if you're interested in working on core, if you start by submitting a full pull requests and everything is turning out well, then we can consider getting you voted in as proper Eclipse committers to the project (which means you can work directly on core) - this would be good as we need more non Red Hat committers on the main project :)

On 21/07/14 11:47, Tim Fox wrote:

Hello folks. I've created a project plan for Vert.x 3.0:

https://drive.google.com/file/d/0B4J2ye6tk2EhTmdBM3ltLVd0eE0/edit?usp=sharing

You can view it using https://stackedit.io (follow the links from the drive url to install)

Tasks are broken down roughly into:

1. Core development - this is stuff that we need to do in the main project

2. "ext" development (extensions). This is stuff that's not core, but will form part of the "stack" that we're going to provide for Vert.x 3.0 application developers.

ext verticles will provide functionality such as database access, IoT services, email and many other things that are commonly wanted when writing Vert.x apps. 

3. Various other things like writing docs, new web site etc.

At this stage, progress has been progressing well on core - most of the Vert.x 3.0 core is complete and we have code generation working now - I already have the generated JavaScript API almost complete and codegen can also be used to generate idiomatic other language APIs for any compliant interface (more on this is another email).

We're now looking to get the community involved in the rest of the development. 

A lot of the remaining work will be in getting the "ext" verticles done. At lot of these won't be written from scratch but can be ported from the Vert.x 2.x versions (e.g. MongoDB module, JDBC module, etc). If you've already been involved in the Vert.x 2 equivalent I would love you to continue helping with the Vert.x 3 versions.

There is also some core work to be done if that is more your bag.

So.. if you're interested in helping you can reply on this thread (or email me privately if you are shy ;) ), and we can hopefully find something appropriate for you (based on your skills, interests and how much time you have to spare).

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nicolaas Frederick Huysamen]

Hi Paolo

I have started some work on a cassandra extension for Vert.x 3, since I will be needing it at some stage also. Have not had too much time to play around with it though. Will try and add some more functionality soon. Or if someone wants to contribute, be my guest.

https://github.com/huysamen/vertx-ext-cassandra

Nico

[Ming Fang]

Tim

Can you offer any more detail on No. Docker?

--ming

[Julien Viet]

Hi,

I started a Docker image for building Vert.x 3 here : https://github.com/vert-x3/vertx-stack/blob/master/Dockerfile

there is a PR I need to review and merge (https://github.com/vert-x3/vertx-stack/pulls).

perhaps you can provide a review and help us improve it.

you can also give feedback because it may be not designed to answer all use cases.

--
Julien Viet
www.julienviet.com

[Julien Viet]

I deployed the current images merged with Nicolas Muller PR in Docker Hub:

https://registry.hub.docker.com/u/vertx/vertx3-exec/
https://registry.hub.docker.com/u/vertx/vertx3/



--
Julien Viet
www.julienviet.com

[Yu Qiao]

Hi Tim,

I'm interested in contributing this project. Could you assign me something? I don't have any preference. I can work 2 hours per day. 

[Francesco Cina]

Hi Tim,

I would be happy to be help you with the developments. I can work for few hours a week in java development.

Cheers

[Jez P]

Hi Tim,

I know it's very late in the day, but it looks like from next week I can have about one day a week to help out for a couple of months (which day will vary from week to week) - Java dev mainly. Happy to help out with small tasks or larger ones which aren't blocking releases (so it doesn't matter if they take a couple of weeks of elapsed time to solve).

So far I've mainly played with a bit of core and a bit of Apex but happy to bring my limited talents to bear anywhere in the codebase :)

Cheers,

Jez

[Tim Fox]

Thanks guys for volunteering, let me have a think and get back to you.

Off the top of my head... some important but not critical path things:

* OAuth support in Apex
* Clojure lang implementation
* Scala lang implementation
* Python lang implementation
* Port Vert.x 2 work queue to V3
* V3 OpenShift cartridge

They're all fairly serious pieces of work, I can probably come up with some smaller stuff too if you're interested :)

--

[Tim Fox]

Thanks guys for volunteering, let me have a think and get back to you.

Off the top of my head... some important but not critical path things:

* OAuth support in Apex
* Clojure lang implementation
* Scala lang implementation
* Python lang implementation
* Port Vert.x 2 work queue to V3
* V3 OpenShift cartridge

They're all fairly serious pieces of work, I can probably come up with some smaller stuff too if you're interested :)

On 26/02/15 09:00, Jez P wrote:

--

[Jez P]

Cheers Tim happy to have a look at OAuth/work queue (neither of which I know well) and see how I get on. If I struggle to make progress fast enough I may ask to be dropped to something smaller. In the first instance I'll have a go at OAuth unless someone else flags up that they desperately want to take it on.

Starting Monday :)

Cheers, 

Jez

[Francesco Cina]

Hi Tim,

I have some proposal about my collaboration:
1) As a software architect and I spend most of my time studying and implementing the architectural pattern for my company's projects. I read complains about the lack or information about how to build "real" size production ready application, which patterns to use, how to organise the code etc. I could start investigating this argument, creating an example web application, and propose/discuss patterns.
2) It is maybe only a personal idea, but I believe that to really hit the market, vertx should be able to integrate with existing de facto standard technology like spring. Could the integration with spring be part of the aforementioned patterns/application? Is there interest in a vertx-spring-boot module?
3) Many developers do not like to work with full featured JPA stacks like Hibernate; nevertheless, manual writing all your SQL statements, as it is required today with vertx, is not a charming alternative, Having been involved for 8 years in the development of a persistence framework alternative to ORM solutions (similar to JOOQ, source code recently released here https://github.com/ufoscout/jporm, the doc is coming), I have good experience with the argument. The project is extremely modularised; one of the modules generates DB-dependent sql code starting from plain java beans; e.g. (pseudocode):

query = findQuery(Employee.class).where().eq("age", 12)
sysout(query.renderSql());
//it prints:
// SELECT Employee.ID AS "id", Employee.NAME AS "name", Employee.AGE AS "age", Employee.SURNAME AS "surname", Employee.EMPLOYEE_NUMBER AS "employeeNumber" FROM EMPLOYEE Employee WHERE Employee.AGE = ?

It is just a simple example. Another modules automatically fills the bean with the returned data. If there is interest, I could investigate an higher abstraction level over vertx3-jdbc (and postgres/mysql) that uses a similar mechanism to avoid SQL handwriting and manual resultset handling.

Cheers
Francesco

[Deven Phillips]

I don't see how manual writing of SQL statements is "required" in Vert.x. I have successfully used Hibernate and jOOQ in Vert.x work verticles and I see no reason it couldn't also be done using Futures and vertx.executeBlocking(Future, Handler).

Cheers,

Deven

[Francesco Cina]

I 100% agree with you.
But, for what I know, with such a strategy you are always forced to work the blocking way and you cannot exploit the real non blocking postegres and mysql modules. Am I wrong?

Cheers
Francesco

[Deven Phillips]

Well, you would have to tell me what you mean by the "non-blocking postgres and mysql modules"... It's a database query, so there will always be at least "some" blocking while waiting on the query to return.

Deven

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/0p-fx926g6o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

[Francesco Cina]

Hi Deven,

with jdbc it is exactly as you are saying, but I was talking about the vertx-mysql-postgresql-service (https://github.com/vert-x3/vertx-mysql-postgresql-service) which is based on fully async drivers (https://github.com/mauricio/postgresql-async). In this case the stack is completely async and free of blocking calls.

Francesco

[Tim Fox]

HI Francesco,

On 02/03/15 08:22, Francesco Cina wrote:

Hi Tim,

I have some proposal about my collaboration:
1) As a software architect and I spend most of my time studying and implementing the architectural pattern for my company's projects. I read complains about the lack or information about how to build "real" size production ready application, which patterns to use, how to organise the code etc. I could start investigating this argument, creating an example web application, and propose/discuss patterns.

We certainly need some end-end examples to go in the examples repo here:

https://github.com/vert-x3/vertx-examples

I would certainly like to see a "real-world" web app with a real front end (e.g. using AngularJS) and some database access at the back end.

2) It is maybe only a personal idea, but I believe that to really hit the market, vertx should be able to integrate with existing de facto standard technology like spring. Could the integration with spring be part of the aforementioned patterns/application? Is there interest in a vertx-spring-boot module?

When you say "integrate with Spring" what does that actually mean? Vert.x 3.0 is a library so should be usable with pretty much any framework, including Spring directly. Do we need any special "integration" here?

Regarding Spring Boot - perhaps you could elaborate on what you are thinking here?

3) Many developers do not like to work with full featured JPA stacks like Hibernate; nevertheless, manual writing all your SQL statements, as it is required today with vertx, is not a charming alternative, Having been involved for 8 years in the development of a persistence framework alternative to ORM solutions (similar to JOOQ, source code recently released here https://github.com/ufoscout/jporm, the doc is coming), I have good experience with the argument. The project is extremely modularised; one of the modules generates DB-dependent sql code starting from plain java beans; e.g. (pseudocode):

query = findQuery(Employee.class).where().eq("age", 12)
sysout(query.renderSql());
//it prints:
// SELECT Employee.ID AS "id", Employee.NAME AS "name", Employee.AGE AS "age", Employee.SURNAME AS "surname", Employee.EMPLOYEE_NUMBER AS "employeeNumber" FROM EMPLOYEE Employee WHERE Employee.AGE = ?

It is just a simple example. Another modules automatically fills the bean with the returned data. If there is interest, I could investigate an higher abstraction level over vertx3-jdbc (and postgres/mysql) that uses a similar mechanism to avoid SQL handwriting and manual resultset handling.

That's an interesting idea. We have discussed ORMs before on this list - but I would warn - ORMs are complex beasts, and it's hard to reuse existing ones because they're generally not non blocking.

[Deven Phillips]

Tim et. al...

We certainly need some end-end examples to go in the examples repo here:

https://github.com/vert-x3/vertx-examples

I would certainly like to see a "real-world" web app with a real front end (e.g. using AngularJS) and some database access at the back end.

I am working on just such an application right now... https://github.com/InfoSec812/vertx-nexus-proxy
I started work on the AngularJS UI last night (not yet committed and pushed). In the end, it will be both a web application and a proxy server to put in front of a Sonatype Nexus server which will provide token based authentication for Nexus. The web application will perform authentication via the proxied Nexus server and will allow for the management of the tokens. Requests to "/nexus/**" will be proxied to the configured Nexus server and set the "REMOTE_USER" token where appropriate. Requests to "/nexus-proxy/**" will provide static content and ReST API endpoints for working with the tokens. It should be done in a matter of days. I may end up eventually adding socks.js/vertx-eventbus websockets for communicating with the backend.


Cheers,

Deven

[Gabriele Santomaggio]

Hello to all,
What about AMQP ? could  I help?
If yes, I have a few question about that:
1. 1.0 or/and 0.9.1 version?
2: Just a client to distribute jobs or embedded/use also a server ?

3: Are you thinking to map address in some way with a routing key?
4: Do you have some guide line/trace/unofficial-document/txt that I can read?

Is it worth it to you?
Have a nice day!

Il giorno lunedì 21 luglio 2014 12:47:28 UTC+2, Tim Fox ha scritto:

Hello folks. I've created a project plan for Vert.x 3.0:

https://drive.google.com/file/d/0B4J2ye6tk2EhTmdBM3ltLVd0eE0/edit?usp=sharing

You can view it using https://stackedit.io (follow the links from the drive url to install)

Tasks are broken down roughly into:

1. Core development - this is stuff that we need to do in the main project

2. "ext" development (extensions). This is stuff that's not core, but will form part of the "stack" that we're going to provide for Vert.x 3.0 application developers.

ext verticles will provide functionality such as database access, IoT services, email and many other things that are commonly wanted when writing Vert.x apps. 

3. Various other things like writing docs, new web site etc.

At this stage, progress has been progressing well on core - most of the Vert.x 3.0 core is complete and we have code generation working now - I already have the generated JavaScript API almost complete and codegen can also be used to generate idiomatic other language APIs for any compliant interface (more on this is another email).

We're now looking to get the community involved in the rest of the development. 

A lot of the remaining work will be in getting the "ext" verticles done. At lot of these won't be written from scratch but can be ported from the Vert.x 2.x versions (e.g. MongoDB module, JDBC module, etc). If you've already been involved in the Vert.x 2 equivalent I would love you to continue helping with the Vert.x 3 versions.

There is also some core work to be done if that is more your bag.

So.. if you're interested in helping you can reply on this thread (or email me privately if you are shy ;) ), and we can hopefully find something appropriate for you (based on your skills, interests and how much time you have to spare).

[Francesco Cina]

Hi Tim,

On Thursday, March 5, 2015 at 12:13:05 PM UTC+1, Tim Fox wrote:

We certainly need some end-end examples to go in the examples repo here:

https://github.com/vert-x3/vertx-examples

I would certainly like to see a "real-world" web app with a real front end (e.g. using AngularJS) and some database access at the back end.

My idea is to create a sample web app that is at the same time a proof of concept and a production ready application. It should be easy to start it locally and to play with it. The business itself has to be a well known one, so interested users can focus on the technical part. For example, a minimal CMS could be ok. An initial set of features could include
- private admin area (purpose: show how to handle authentication/authorisation) where an admin can create new posts (interaction with DB)
- public area that shows the blog entries (read from mongoDB?)
- There could be also a way of registering to the blog using Social Network accounts (purpose: show interaction with social networks)
- connected users can start a chat and receive notifications (purpose: show eventbus and websockets integration)

Tech stack: Angularjs, Angular-UI, Postgres/MySQL, MongoDB(?), Apex (REST services), Vertx3 (...of course ;) ). Spring for dependency injection?

2) It is maybe only a personal idea, but I believe that to really hit the market, vertx should be able to integrate with existing de facto standard technology like spring. Could the integration with spring be part of the aforementioned patterns/application? Is there interest in a vertx-spring-boot module?

When you say "integrate with Spring" what does that actually mean? Vert.x 3.0 is a library so should be usable with pretty much any framework, including Spring directly. Do we need any special "integration" here?

Regarding Spring Boot - perhaps you could elaborate on what you are thinking here?

To bre honest, I don't have a clear idea, but it seems that everybody is in love with Spring boot today (me too...) so it could be interesting to show how vertx3 can be easily used with it.
 

3) Many developers do not like to work with full featured JPA stacks like Hibernate; nevertheless, manual writing all your SQL statements, as it is required today with vertx, is not a charming alternative, Having been involved for 8 years in the development of a persistence framework alternative to ORM solutions (similar to JOOQ, source code recently released here https://github.com/ufoscout/jporm, the doc is coming), I have good experience with the argument. The project is extremely modularised; one of the modules generates DB-dependent sql code starting from plain java beans; e.g. (pseudocode):

query = findQuery(Employee.class).where().eq("age", 12)
sysout(query.renderSql());
//it prints:
// SELECT Employee.ID AS "id", Employee.NAME AS "name", Employee.AGE AS "age", Employee.SURNAME AS "surname", Employee.EMPLOYEE_NUMBER AS "employeeNumber" FROM EMPLOYEE Employee WHERE Employee.AGE = ?

It is just a simple example. Another modules automatically fills the bean with the returned data. If there is interest, I could investigate an higher abstraction level over vertx3-jdbc (and postgres/mysql) that uses a similar mechanism to avoid SQL handwriting and manual resultset handling.

That's an interesting idea. We have discussed ORMs before on this list - but I would warn - ORMs are complex beasts, and it's hard to reuse existing ones because they're generally not non blocking.

I should be able to show some working code before the end of the month. It will be something closer to JOOQ than to a complete ORM. In fact, I don't see how the usual ORM/JPA patterns (stateful objects, lazy loading, etc...) could apply to a reactive world; I am convinced that a lower level JOOQ like solution in this case works best.

Regards
Francesco

[Tim Fox]

On 07/03/15 15:30, Francesco Cina wrote:

Hi Tim,

On Thursday, March 5, 2015 at 12:13:05 PM UTC+1, Tim Fox wrote:

We certainly need some end-end examples to go in the examples repo here:

https://github.com/vert-x3/vertx-examples

I would certainly like to see a "real-world" web app with a real front end (e.g. using AngularJS) and some database access at the back end.

My idea is to create a sample web app that is at the same time a proof of concept and a production ready application. It should be easy to start it locally and to play with it. The business itself has to be a well known one, so interested users can focus on the technical part. For example, a minimal CMS could be ok. An initial set of features could include
- private admin area (purpose: show how to handle authentication/authorisation) where an admin can create new posts (interaction with DB)
- public area that shows the blog entries (read from mongoDB?)
- There could be also a way of registering to the blog using Social Network accounts (purpose: show interaction with social networks)
- connected users can start a chat and receive notifications (purpose: show eventbus and websockets integration)

Tech stack: Angularjs, Angular-UI, Postgres/MySQL, MongoDB(?), Apex (REST services), Vertx3 (...of course ;) ). Spring for dependency injection?

Sounds interesting - but I'm not sure about the Spring part.

Demonstrating that Vert.x can work well with Spring would be a good subject for an example, but I'm not sure it should be part of a recommended architecture for Vert.x. Perhaps I just haven't understood what Spring would add here.

2) It is maybe only a personal idea, but I believe that to really hit the market, vertx should be able to integrate with existing de facto standard technology like spring. Could the integration with spring be part of the aforementioned patterns/application? Is there interest in a vertx-spring-boot module?

When you say "integrate with Spring" what does that actually mean? Vert.x 3.0 is a library so should be usable with pretty much any framework, including Spring directly. Do we need any special "integration" here?

Regarding Spring Boot - perhaps you could elaborate on what you are thinking here?

To bre honest, I don't have a clear idea, but it seems that everybody is in love with Spring boot today (me too...)

Perhaps you could explain a bit why you love it some much? AIUI, Spring Boot is a way of starting Spring applications quickly in a main() method.

Which is a similar approach to what Vert.x does anyway. So I guess what I am missing is what Spring Boot brings to the party and what Vert.x doesn't have that puts it at a disadvantage. I would really love you to elaborate on this point so I have a better understanding :)

so it could be interesting to show how vertx3 can be easily used with it.
 

3) Many developers do not like to work with full featured JPA stacks like Hibernate; nevertheless, manual writing all your SQL statements, as it is required today with vertx, is not a charming alternative, Having been involved for 8 years in the development of a persistence framework alternative to ORM solutions (similar to JOOQ, source code recently released here https://github.com/ufoscout/jporm, the doc is coming), I have good experience with the argument. The project is extremely modularised; one of the modules generates DB-dependent sql code starting from plain java beans; e.g. (pseudocode):

query = findQuery(Employee.class).where().eq("age", 12)
sysout(query.renderSql());
//it prints:
// SELECT Employee.ID AS "id", Employee.NAME AS "name", Employee.AGE AS "age", Employee.SURNAME AS "surname", Employee.EMPLOYEE_NUMBER AS "employeeNumber" FROM EMPLOYEE Employee WHERE Employee.AGE = ?

It is just a simple example. Another modules automatically fills the bean with the returned data. If there is interest, I could investigate an higher abstraction level over vertx3-jdbc (and postgres/mysql) that uses a similar mechanism to avoid SQL handwriting and manual resultset handling.

That's an interesting idea. We have discussed ORMs before on this list - but I would warn - ORMs are complex beasts, and it's hard to reuse existing ones because they're generally not non blocking.

I should be able to show some working code before the end of the month.

Sounds great :)

It will be something closer to JOOQ than to a complete ORM. In fact, I don't see how the usual ORM/JPA patterns (stateful objects, lazy loading, etc...) could apply to a reactive world; I am convinced that a lower level JOOQ like solution in this case works best.

Regards
Francesco

[Jez P]

Spring Boot does a bit more than that Tim, it also analyses what's on your classpath and sets up default configs (e.g. ORM setup, container-based webapp setup) to avoid those annoying web.xml and persistence.xml files. You can tweak these configs as desired, but basically it identifies the likely elements you want in your application and puts them there, so you can focus on coding rather than those config elements (which always take disproportionate time when spinning up a new project).

It also embeds performance stats etc, it's almost a container within a container ;)

That said, I'm still not quite sure why it would need to be part of a default stack. If the only thing you're going to use Spring for is DI, you probably shouldn't use Spring at all, you can do DI without it perfectly easily, and generally with fewer lines of code/config combined. Agree with you that it's fine to show how vert.x and Spring play nicely together, but I don't see that the stack benefits much from having it there. Where Spring could come in useful in a demo application is if it offers libraries for external interaction that aren't yet available directly in vert.x 3, but I'm not convinced that Spring Boot would play much part (and I quite like Spring Boot).

Just my threepence worth :)

[Paulo Lopes]

On Sunday, March 8, 2015 at 9:42:33 AM UTC+1, Jez P wrote:

Spring Boot does a bit more than that Tim, it also analyses what's on your classpath and sets up default configs (e.g. ORM setup, container-based webapp setup) to avoid those annoying web.xml and persistence.xml files. You can tweak these configs as desired, but basically it identifies the likely elements you want in your application and puts them there, so you can focus on coding rather than those config elements (which always take disproportionate time when spinning up a new project).

It also embeds performance stats etc, it's almost a container within a container ;)

I do not totally agree with the benefits, first vert.x has no web.xml so the plus point here is not a plus at all it is bloat, second the persistence.xml is specific to hibernate and alike ORMs, there are a ton of others out there that do not use it. For example in a project i am working we are using Postgres with all its new fancy features like common table expressions, window functions, and even considering JSONB in our case Mybatis made much more sense since it is a a simple java interface to sql statement mapper which only needs to have injected a data source. I can get a datasource directly from the jdbc driver avoiding xml, spring, etc...

 

That said, I'm still not quite sure why it would need to be part of a default stack. If the only thing you're going to use Spring for is DI, you probably shouldn't use Spring at all, you can do DI without it perfectly easily, and generally with fewer lines of code/config combined. Agree with you that it's fine to show how vert.x and Spring play nicely together, but I don't see that the stack benefits much from having it there. Where Spring could come in useful in a demo application is if it offers libraries for external interaction that aren't yet available directly in vert.x 3, but I'm not convinced that Spring Boot would play much part (and I quite like Spring Boot).

I totally agree, Vert.x is a very lightweight framework that we can use to build microservices where each microservice can be seen as a module in the old 2.x naming. If one addresses services as just a address and complies to some json schema, then why do we need a DI at all? if you want another implementation, it is just a matter of the address you use.

Now what i am trying to state here is that I've been using Vert.x, Yoke, and lots of other components in a complex SaaS microservice application with lots of components and I started initially with Spring because... you know if you do java you use Spring... until i've noticed the overhead of slow starts due to spring booting itself, generating proxies for all beans and so on and then I've noticed that I could just remove it and still have the exactly same flexibility on my app.

By removing Spring from the equation the whole deployment is faster, just imagine that you don't need to bring all the spring jars, no need to configure application context xml files or java config.

Off course there where places where it made sense to use a DI and in this case I had to choose between Spring, Google Guice, etc and ended up picking the one that would bring less bloat. In my case it was Guice but this depends on what are you DI in your code.

[Jez P]

Just to be clear I wasn't talking about the benefits of Spring Boot in a vert.x context, just pointing out that Spring Boot is more than just starting up a Spring application. Spring Boot is a very useful easy startup for developing a new Spring application if you want stuff like Hibernate/web containment etc made easy, and offers plenty of nice add-ons. In effect Spring Boot is a quick way to go from no application to a Spring application with minimal headache. I completely agree that Spring shouldn't just be in the stack "because Spring" (and I also completely agree with you that Spring is often used when there is absolutely zero need for it). 

What people ignore all too often is that constructor parameters and (if you really must) setters are all you actually need for DI. You don't need Spring to do DI, you can write your own bootstrapper that assembles your application from the classes you define - your bootstrapper is doing all the dependency injection if you do it right. Unless you're going to use Spring for things beyond DI, then using Spring is very questionable. And I'm speaking as - in general - a fan of Spring. If you build a Spring context, the first thing you should ask yourself is "Why am I not just assembling this set of dependencies in a Java class without all the Spring proxying?"

As I said, I don't really see any place for Spring Boot in a "standard" vert.x technology stack, and I don't think we should try to shoehorn it into a fully featured vert.x webapp just so we can say "and look, there's a place for Spring", so I would say start without Spring/Spring Boot and see if we really need it in the stack (and if so, examine why it's needed in case it makes more sense to fix some deficiency in vertx-ext).

[Francesco Cina]

Hi Tim,

Spring is much, much more than a call to the main method. It is the de facto standard in the Java enterprise world and today a huge part of the java community definitely has a spring-based mind. I am planning an internal talk in my company to present vertx, I already know that if the demo application of the talk is not based on Spring, nobody will listen to me. Or better, they will listen to me but they will not play with the code. The enterprise world is conservative, an evolution could be taken into account more easily than a revolution.
To summarize, I mentioned Spring not because it is needed, but because I think that it is the entry point of a wider world.
In addition, it has been said that dependency injection is not needed since vertx has modules/services; I don't get exactly this point. In fact, even in a microservices architecture DI is always needed; it is needed not to inject a service into another one but to inject/decouple internal components of a single service. For example, I could have a vertx service A, this service internally has 10 DAOs, 10 bean converters, and 10 facades. Suppose that each facade needs some of the DAOs and some the bean converters; and suppose that in the facade classes the vertx eventbus is use to create events to be consumed by other services. The question is, if not DI, which pattern to you use to access the needed DAOs and bean converters in the facade? I have seen too many applications where, to cope with this problem, most of the code was written in public static methods!!! :(
However, I am not trying to push Spring in the default stack; I am only really interested in the argument and eager to know other point of views.
To summarise:
- from a technical point of view I think a DI framework is needed (there are many lightweight alternatives)
- from a political point of view I think that there are advantages in terms of audience if that DI framework is spring.

One of the main objectives of creating a production ready sample is to investigate the needed patterns; in this scope, this discussion is perfect ;)

[dgo...@squaredfinancial.com]

On Sunday, 8 March 2015 10:58:34 UTC, Paulo Lopes wrote:

Off course there where places where it made sense to use a DI and in this case I had to choose between Spring, Google Guice, etc and ended up picking the one that would bring less bloat. In my case it was Guice but this depends on what are you DI in your code.

Just to mention Dagger here* - it's very light and I've merrily used it within vertx2 apps before.  There was a terminological clash insofar as vertx2 uses the term "module" and so does dagger for something entirely different, but meh, that goes away with vertx3 anyway.

While I'm just naming things, rather than full ORM and rather than using one of the generic vertx rdbms persistors we have in the past used app-specific "domain-specific persistors"  i.e. rather than the persistor processing messages containing "raw" sql operations to do a la mod-mysql-postgresql or whatever ("insert into table user_prefs"), it is processes messages working in terms of domain objects ("save these user prefs please") and persists them to rdbms with sql2o (lightweight not-an-orm) underneath as appropriate (and using flywaydb (no-nonsense migrations) to manage the db schema).  Just a slightly different abstraction layering than you get with the generic persistors, but one that has worked well for us.

(* company name similarity (square/squared) coincidental, not the same people as current employer)

[Feuer Au]

Hi Francesco:

I agree with you, many people use Spring framework instead of public static method to inject instances and use their methods and it works pretty good in Java world

But in Vert.x the thing is a little bit different since in pure Java environment the class structure can be shared by different method for instance

there are two methods one in DAO another one in Facade, let us called them daoFunc & facadeFunc and both functions accept the same class/object structure

let's say the structure is called myObject, and in myObject there are some private fields and set/get methods etc.

by using Spring we could use dao.daoFunc in the facade object, thus actually the parameter is passed from facadeFunc(obj) -> daoFunc(obj);

however since the Vert.x is polyglot thus the creators have to take different languages into account

let's say if there is another Verticle written in another languages like Python, assume DAO Verticle is written in Python

thus how to inject a Python method into a Java class? The languages are different and standards are different...

therefore the only way to copy with this is use the same data format that every languages could accept and are able to parse which is Json or XML or other text format object

thus the actual way of passing data is facadeFunc(obj) -> send(obj -> json) -> handle(json and parse it) -> daoFunc(obj)

There are two extra steps one is to generate Json message and the other is to parse the Json message into the language object

It is a little bit more complicated but this is how the bus works, think of there are two different IT systems one written in Ruby another is written in Java

then the way to integrate these two systems is using web service(restful probably) and the Vert.x itself is like a small integration of different Verticles

and each Verticle is a small system of each language. Thus we do need a message broker and the bus is the broker.

 

If the creators like Tim add in Spring as DI framework then how the Spring works for the other languages?

Like how to inject a method written in Ruby into a Python Verticle? I don't see a solution for this

thus it is better to keep Spring as separate framework and probably you could find a way to integrate the Spring framework into a Verticle

I saw there is start method in Vert.x 3 and you may use this method to initiate the Spring framework and scan the class path to generate 

singleton instance of different methods. 

Besides, I think different languages use different way to write the code, for example for those functional programming language like

Clojure and Scala, the functions are 1st class citizen thus there is no need to create public static methods or using Spring framework

they could use 1st class citizen functions to do the similar idea without injecting objects.

Hope this would help

Cheers

[Feuer Au]

Hi Tim:

I got two suggestions maybe useful

1) Is it possible to use Annotation rather than extending an abstract class?

Like

@Verticle

class MyClass{

...}

and similarly for start method

@Start

public void myMethod(..)

rather than using @Override

2) Config file support

Create an global config file in config.json or config.xml or config.properties 

and in this config file users could define like

<xml>

    <verticle="edu.university.MyClass"/>

    <verticle="src/edu/ruby/Helloworld.ruby"/>

...

</xml>

or in Json

{

verticle: "edu.university.MyClass",

verticle: "src/edu/ruby/Helloworld.ruby"

}

etc.

and then use command 

vertx run config.xml or vertx run config.json etc.

Hope these would help

Cheers

[Jordan Halterman]

@Verticle and @Start feel like gross abuses of annotations to me. Verticle is a type of object, and start is a function of that object, so I see absolutely no argument against this standard OOP design, nor did you provide one.

What is the argument against Verticle and Verticle#start?

--

[Feuer Au]

Hi Jordan:

Dont get me wrong, I did not say we should abandon the AbstractVerticle class. We should keep this way for sure, since it is simple and easy to understand and by using this, we could lower the entry barrier that everybody could pick up this tool and code very quickly.

But let us take a look at the history of Java enterprise development especially the evolve of EJB and Spring

For EJB2, the JCP uses the traditional way which is exactly like what we do here, they define several Interfaces(Remote and Local) and then ask people to implement these interfaces etc. and we all knew it did not prevail later. Why? Because the Spring said we dont need those interfaces and all users need to do is to register their Java beans in a xml files. Then the Spring could handle the rest. So this is the inspiration of the second way, we could define the Verticle in a config file and then use the Vert.x to invoke these beans without explicitly saying this is a Verticle instance just like Spring did many years ago.
 
And many years later, the Spring has evolved to another way which is using Annotation, they are actually using Component, Repository, Service etc. and EJB3 also define the new way to create an EJB by using annotations like EJB, Stateless, Stateful, Singleton etc. Basically all these so-called components, services, repositories, ejbs, stateless ejbs are actually objects for sure, but by using the Component and other annotations make the development more easier to do since most people do not really care about what the framework does, all they need is just tell the framework, hey get this done, then they go away to do what they really need to do which is coding their own logic probably. And this situation would become more interesting when the user defined their own super class. For instance if the users define one class BookService as their own abstract class and they packed this as a jar file then if the user needs to extend this abstract class let's called MyBookService, and then define this MyBookService as a verticle how they gonna do this? There is no way to extends two different super classes in Java. You can't do it like this
class MyBookService extends BookService, Verticle{
}
but using annotation would make things easier like this
@Verticle
class MyBookService extends BookService{
...//todo
}
done.

Summary:
We should keep the current way of creating verticle for sure, I agree with you, this is the standard OO way to create instances.
but we could expand current way to another two different ways which is pretty similar to the ways how Spring & EJB do.
and this suggestion only involve Java verticles since the other programming languages may not be able to support reflection and annotation
thus it is probably difficult to implement this idea to other language verticles.

Hope this would help

Cheers

[Feuer Au]

and for the structure like this would be much much more beautiful since

@Verticle <- this is the Vert.x job and only write this because of using Vert.x and this idea is created by Vert.x not users
class MyBookService extends BookService{ <- from here, all codes are created by users themselves not Vert.x really care
...//todo
}

similar to Spring codes like
@Service

class MyBookService extends BookService{
...//todo
}

[Jordan Halterman]

I think this is an area where Vert.x has to be careful. Even though Vert.x is written in Java, it caters to a variety of languages that share various features with Java, but far from all features. I think what's most important for teams that work with Vert.x in multiple languages (including mine) is that Vert.x provide a fairly consistent interface across different languages with an emphasis on each respective language's features to some extent.

Sure, what you're proposing is using a Java feature for Java verticles. But I submit that the type system - classes and interfaces - is what should be used to define types and behaviors, regardless of what Spring and enterprise applications have done in the past. I'll be frank: I'm biased. In my opinion Spring went a little (a lot?) too far in replacing language features with annotations, and that's precisely what I'm talking about here. Vert.x and other innovative JVM projects have made progress towards simplicity by unraveling the progress towards complexity of enterprise Java systems.

Back to the proposal at hand...

Exposing two different methods of implementing verticles simply increases complexity with little benefit. You made the argument that annotations essentially allow multiple inheritance when combined with dependency injection (the BookService example), but a BookService instance can just as easily be instantiate within a Verticle as well, and indeed this I think makes for a better design. Multiple inheritance and merging the BookService type and the Vert.x specific Verticle and all of its implementation details feels a lot like multiple responsibilities to me.

The problem is, using annotations in the manner that you suggest adds complexity to Java verticles that is often not present in Vert.x verticles written in other languages. For instance, there's no equivalent multiple inheritance like strategy with which I could combine an existing Python script into a Python script/Vert.x verticle. Instead, I create a Python Verticle which loads the necessary libraries used by that Verticle, and I delegate message handling to the underlying library. This is a consistent pattern across my Python, Java, and Javascript verticles, and that architecture might otherwise be violated by the rather opaque behavior of annotations.

In my opinion, the core Vert.x developers are doing great in managing the relationships between the various languages while still using the powerful features of the Java language - including annotations - where it's necessary. For instance, the code generation framework uses annotations to provide metadata about types and parameters to templates. This is an excellent use of annotations as it adds additional information not supported by Java's type system itself. For standard Vert.x types, OOP provides encapsulation, inheritance, and polymorphism, all of which are enforced natively by the Java compiler, and we ought to use that solution rather than trying to solve the same problem in another way.

Consistency consistency consistency.

[Tim Fox]

Hi Francesco,

On 10/03/15 08:29, Francesco Cina wrote:
> Hi Tim,
>
> Spring is much, much more than a call to the main method.

I understand that Spring Framework is, when I was referring to the
main() method I was specifically referring to Spring *Boot*, not Spring
Framework in general ;)

Great. As I mentioned before, it would be a nice to see an example
application that uses Spring with Vert.x.

Personally I'm not a huge fan of DI, but I understand some people like
it, and that's fine.

Also, one issue with using Spring with Vert.x (as others have pointed
out) is that most of Spring is not async.

>