Taking Vert.x to the next level - Vert.x 2.0

[Tim Fox]

During Devoxx I started to think about what we need to do to take Vert.x to the next level. There is currently a lot of interest in Vert.x that we need to build on, but there's also quite a lot we need to do to gain acceptance in the enterprise.

I would therefore like to start working in the next few weeks on the next major release - vert.x 2.0.

Some of the things I'd like to consider including in this release are:

1. Classloader refactoring.

Currently each verticle/module runs in its own classloader instance. The main reason for this is to provide isolation by preventing instances to share data using statics.

However this has problems including permgen getting easily exhausted as each instance has its own copy of classes including copies of classes from any other jars that it uses. This doesn't scale.

Other issues include not being able to put user defined classes in a Shared map and share them between module instances.

I'd therefore like to change the classloading module such that each module/verticle *type* (not instance) has its own classloader instance. This means classes would only be loaded for a module once, not once per instance. This is a more traditional model you'd find in most app servers.

The down side of this is users will be able to share data using static members between instances of the same module/verticle. But I think this is a price worth paying. (We can warn against this).

2. IDE integration.

We need good Eclipse/IntelliJ integration.

Personally I don't use IDEs for anything much more than editing files, but I'm probably in a minority.

We need the Gradle tasks to work properly for creating Eclipse/IntelliJ projects (currently they are broken).

We need an effortless way of easily testing Vert.x verticles/modules from within an IDE. I'm guessing we need an Eclipse + IntelliJ plugin here.

We need a way of effortlessly creating Vert.x projects from an IDE or command line in a "best-practice" project layout. We need to decide what the best practice is first!

3. Management / monitoring

Ops need to be able to manage Vert.x servers in production.

Pid has started some good work here including a GUI. I would like to see this in Vert.x 2.0

4. Multi-threaded workers

(This came up after some feedback from Chris Richardson @ VMware)

Writing some kinds of worker verticles that use traditional Java APIs such as JDBC is quite awkward since worker verticles are single threaded. It would be much simpler to be able to write a multi-threaded worker verticle which managed a JDBC pool directly. A multi-threaded verticle could receive messages on the same handler instance concurrently.

This wouldn't be commonly used and wouldn't be the default, but would be very useful in writing plugin modules for stuff like JDBC, other database stuff, mailers etc. 

5. Avoiding callback spaghetti.

It's a well known issue of asynchronous frameworks/platforms such as Vert.x/Node.js/Akka/Play etc that direct use of asynchronous APIs can result in so-called "callback spaghetti" and it becomes hard to reason about control flow.

Some frameworks (e.g. Play/Akka also stuff like kaolan-async JS) tackle this by providing some kind of "promises" or "deferreds" API which allows you to combine asynchronous actions into different control flows. We had something like this in earlier versions of Vert.x but I removed it because it was quite clunky.

Creating a good promises API is tricky and we'd actually have to produce multiple APIs - one for each language we support!

Another way of solving this problem is by using continuations/coroutines to provide an old-fashioned direct-style (i.e. logically synchronous) API, but which doesn't actually block OS threads. The problem with this is the JVM has no first class support for continuations so you have to do this via byte code manipulation. There are a few projects that handle this e.g. JavaFlow/Kilim but it's not clear to me at this point how feasible it would be to do this.

If we could use a continuations approach this could be provided in a module which uses the core API.

6. Separate language support out into modules. 

This would mean the core Vert.x installation would be small and you'd only download and install particular language support if you actually used it.

7. HA support.

I am leaning towards an Erlang-like supervisor model. But we need a solution here if we're to be seriously considered in many production environments.

8. Scala and Clojure Support.

9. Various other smaller stuff including:

* Some improvements to the core API, e.g. HttpClient

* Upgrade to latest version of SockJS

* Upgrade to Netty 4

If you have any more suggestions about stuff you really think should be included in Vert.x 2.0, please suggest away!

In particular I'm interested in hearing from people who have already used Vert.x in real projects, and the problems you found, so we can fix them for Vert.x 2.0

[Stephane Bastian]

Hi Tim,

+1 for everything you listed

I'll like to add the following items to the list:

1. Grow the Vertx community by making it easy for people to contribute. As you said Vertx is getting quite a bit of traction which is great and exciting but that's not enough. The number one (minor) issue I personally had with Vertx, had to do with the build system. Gradle is certainly great but like a majority of people out there, I'm used to Maven. Let's reuse the tools people are used-to and lets make it dead simple for them to help us improve Vertx. In others words lets migrate the build system from Gradle to Maven, it should only take a couple of hours. It will also help with you second item 'IDE integration' since Maven is nicely integrated with the major IDEs

2. MVC
A lot of people develop web apps. Lets provide a top notch MVC to Vertx. Akka has the Play framework. We need something like it. But not a port of Spring/Struts2/you name it/ to Vertx. A simple yet extremely powerful MVC made especially for Vertx. I recently developed some building blocks of an MVC:
- A brand new template engine, logic-less, type safe that compiles to Java code (using a syntax such as @if(...) @for(...) )
- An xText plugin that reads a file containing routes (similar to the Play framework) and compile them to java code. It takes care of the following:
   - It routes the request to the correct controller and bind/convert request parameters to the arguments of the controller method that handles the request.
   - It provides a way to create the URL that must be generated from a View (along with the correct parameters).
   - The plugin is already integrated in Eclipse and automatically re-compiles the java code each time a route is changed

I may be able to contribute some/all of the code to Vertx. Before i've got to check what the implications are for my company.

All the best,

Stephane

[Pid]

On 21/11/2012 14:31, Stephane Bastian wrote:
> Hi Tim,
>
> +1 for everything you listed
>
> I'll like to add the following items to the list:
>
> 1. Grow the Vertx community by making it easy for people to contribute.
> As you said Vertx is getting quite a bit of traction which is great and
> exciting but that's not enough. The number one (minor) issue I
> personally had with Vertx, had to do with the build system. Gradle is
> certainly great but like a majority of people out there, I'm used to
> Maven. Let's reuse the tools people are used-to and lets make it dead
> simple for them to help us improve Vertx. In others words lets migrate
> the build system from Gradle to Maven, it should only take a couple of
> hours. It will also help with you second item 'IDE integration' since
> Maven is nicely integrated with the major IDEs

-1 from me.

It's already been shown that it took longer to assemble a working Maven
build for vert.x.

Gradle integration in IDEs is increasingly common; all of the major IDEs
already have it.

The current build /could/ be more simple; extracting the languages as
modules and localising the tests to each subproject will do much of the
work. Moving to Maven when many people are moving away from that tool
is not the right call IMO.

OTOH making it easier to develop vert.x applications using Maven is a
wholly different thing & one that I'd fully support.


p

> 2. MVC
> A lot of people develop web apps. Lets provide a top notch MVC to Vertx.
> Akka has the Play framework. We need something like it. But not a port
> of Spring/Struts2/you name it/ to Vertx. A simple yet extremely powerful
> MVC made especially for Vertx. I recently developed some building blocks
> of an MVC:
> - A brand new template engine, logic-less, type safe that compiles to
> Java code (using a syntax such as @if(...) @for(...) )
> - An xText plugin that reads a file containing routes (similar to the
> Play framework) and compile them to java code. It takes care of the
> following:
> - It routes the request to the correct controller and bind/convert
> request parameters to the arguments of the controller method that
> handles the request.
> - It provides a way to create the URL that must be generated from a
> View (along with the correct parameters).
> - The plugin is already integrated in Eclipse and automatically
> re-compiles the java code each time a route is changed
>
> I may be able to contribute some/all of the code to Vertx. Before i've
> got to check what the implications are for my company.
>
> All the best,
>
> Stephane
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/vertx/-/wrE2P-SHCqAJ.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.


--

[key:62590808]

[Pid]

On 21/11/2012 13:12, Tim Fox wrote:
> During Devoxx I started to think about what we need to do to take Vert.x
> to the next level. There is currently a lot of interest in Vert.x that
> we need to build on, but there's also quite a lot we need to do to gain
> acceptance in the enterprise.
>
> I would therefore like to start working in the next few weeks on the
> next major release - vert.x 2.0.

Are you going to leave a maintenance branch behind in 1.x? There are
potentially enough people using it that this might be wise.

> 2. IDE integration.
>
> We need good Eclipse/IntelliJ integration.
>
> Personally I don't use IDEs for anything much more than editing files,
> but I'm probably in a minority.
>
> We need the Gradle tasks to work properly for creating Eclipse/IntelliJ
> projects (currently they are broken).

I'll take this on.



p

[Tim Fox]

On 21/11/12 14:42, Pid wrote:
> On 21/11/2012 13:12, Tim Fox wrote:
>> During Devoxx I started to think about what we need to do to take Vert.x
>> to the next level. There is currently a lot of interest in Vert.x that
>> we need to build on, but there's also quite a lot we need to do to gain
>> acceptance in the enterprise.
>>
>> I would therefore like to start working in the next few weeks on the
>> next major release - vert.x 2.0.
> Are you going to leave a maintenance branch behind in 1.x? There are
> potentially enough people using it that this might be wise.

Yes, we should do the work on different branches

>
>> 2. IDE integration.
>>
>> We need good Eclipse/IntelliJ integration.
>>
>> Personally I don't use IDEs for anything much more than editing files,
>> but I'm probably in a minority.
>>
>> We need the Gradle tasks to work properly for creating Eclipse/IntelliJ
>> projects (currently they are broken).
> I'll take this on.

You're welcome, but don't take on too much - you already have management
and Scala, which seems quite a lot to me!
>
>
> p


--
Tim Fox

Vert.x - effortless polyglot asynchronous application development
http://vertx.io
twitter:@timfox

[Harry2010]

Tim,

I run a technology incubator and I am very interested in Vertx and its possible uses in the enterprise. I think of the many good ideas you have in mind, porting to Netty 4.0 is most important for our platform needs. I have been holding off spending resources on Vertx currenlty simply because of this. The differences between Netty 4.0 and earlier versions are a hindrance to adopting the current Vertx. I am not sure yet, whether to fully exploit the changes in Netty, Vertx thread models need to change too. So much so that for the moment we have decided simply to start with building java script environment to work with Netty 4.0 Alpha. So, my request is that we make moving to Netty 4.0 a priority rather than a small item tucked in the end. I am willing to put my money into this provided you can help with with finding the right person. gopi

[Tim Fox]

Can you explain a bit more why upgrading to Netty 4.0 is so important
for you?

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/GYl5dWXiD3AJ.

> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.

[Tim Fox]

If anyone wants to volunteer for any of this tasks, that would be great :)

I'm going to take the classloading, mult-threaded workers and continuations/promises but all the others are up for grabs

[Tim Fox]

On Wednesday, November 21, 2012 2:31:47 PM UTC, Stephane Bastian wrote:

Hi Tim,

+1 for everything you listed

I'll like to add the following items to the list:

1. Grow the Vertx community by making it easy for people to contribute. As you said Vertx is getting quite a bit of traction which is great and exciting but that's not enough. The number one (minor) issue I personally had with Vertx, had to do with the build system. Gradle is certainly great but like a majority of people out there, I'm used to Maven. Let's reuse the tools people are used-to and lets make it dead simple for them to help us improve Vertx. In others words lets migrate the build system from Gradle to Maven, it should only take a couple of hours. It will also help with you second item 'IDE integration' since Maven is nicely integrated with the major IDEs

I know where you're coming from but build tools are a contentious issue, especially in Vert.x.

People have strong opinions on either side of the argument here. 

If it was me I would just use ant but I know that wouldn't go down very well ;)

 

2. MVC
A lot of people develop web apps. Lets provide a top notch MVC to Vertx. Akka has the Play framework. We need something like it. But not a port of Spring/Struts2/you name it/ to Vertx. A simple yet extremely powerful MVC made especially for Vertx. I recently developed some building blocks of an MVC:
- A brand new template engine, logic-less, type safe that compiles to Java code (using a syntax such as @if(...) @for(...) )
- An xText plugin that reads a file containing routes (similar to the Play framework) and compile them to java code. It takes care of the following:
   - It routes the request to the correct controller and bind/convert request parameters to the arguments of the controller method that handles the request.
   - It provides a way to create the URL that must be generated from a View (along with the correct parameters).
   - The plugin is already integrated in Eclipse and automatically re-compiles the java code each time a route is changed

I may be able to contribute some/all of the code to Vertx. Before i've got to check what the implications are for my company.

Agreed, a good templating system is a must for Vert.x. I would see this as a module in vert.x 

All the best,

Stephane

[Brian Lalor]

On Nov 21, 2012, at 9:39 AM, Pid <p...@pidster.com> wrote:

>> Let's reuse the tools people are used-to and lets make it dead
>> simple for them to help us improve Vertx. In others words lets migrate
>> the build system from Gradle to Maven, it should only take a couple of
>> hours. It will also help with you second item 'IDE integration' since
>> Maven is nicely integrated with the major IDEs
>

> It's already been shown that it took longer to assemble a working Maven
> build for vert.x.

Could you explain, please? Are you talking execution time? I do see that Gradle is faster, but I think we're talking 60s vs 120s with Maven.

I already ported the build to Maven once and I'd jump at the opportunity to do it again. It was easy, and the benefit to others wanting to jump in would be huge. I'm extremely reluctant to develop on the Vert.x core because the Gradle build is a nightmare to comprehend. Maven has its flaws, but it has a huge mindshare and once you learn it once, you know it for all projects. It appears that every Gradle build is the developer's invention, like the Bad Old Days of ant.

Also, the Maven build I created didn't require any environment setup at all. Jython, JRuby,etc were set up as dependencies for the build process. Today you have to download and install them yourself. With the maven build, you clone the repo and run "mvn package" and you're done. No thought required.

[Tim Yates]

See, I'm the exact opposite, avoid maven wherever possible and find Gradle to be much nicer...

Tim

On 21 November 2012 16:30, Brian Lalor <bla...@bravo5.org> wrote:

Could you explain, please?  Are you talking execution time?  I do see that Gradle is faster, but I think we're talking 60s vs 120s with Maven.

I already ported the build to Maven once and I'd jump at the opportunity to do it again.  It was easy, and the benefit to others wanting to jump in would be huge.  I'm extremely reluctant to develop on the Vert.x core because the Gradle build is a nightmare to comprehend.  Maven has its flaws, but it has a huge mindshare and once you learn it once, you know it for all projects.  It appears that every Gradle build is the developer's invention, like the Bad Old Days of ant.

Also, the Maven build I created didn't require any environment setup at all.  Jython, JRuby,etc were set up as dependencies for the build process.  Today you have to download and install them yourself.  With the maven build, you clone the repo and run "mvn package" and you're done.  No thought required.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

[bytor99999]

OK, I agree with all the things considered. Especially the callback spaghetti. But probably most important to me, and the #1 issues I would like to see in vert.x and it has to be unobstrusive (which is the tricky part) And that is 100% easy integration with the Spring Framework. A simple way to create an ApplicationContext and have access to it in any verticle. But either have only one instance of it per verticle, or per vert.x application.

I am tired of have to architect fully to so many callback spaghetti and write so much more code in vert.x that I could have so easily and quickly done with Spring. Accessing data with Spring data. Setting up an easier control flow with Spring Integration. But instead of taking days, it will take weeks/months to write the same code without Spring.

I know I have brought this up too many times, but I really think this would open up the flood gates for a lot more people to start using vert.x

Thanks

Mark

On Wednesday, November 21, 2012 5:12:01 AM UTC-8, Tim Fox wrote:

[Harry2010]

Tim,

Broadly speaking there are quite a few major changes to the chanel and thread models in Netty 4.0 that it will be better to allign Vertx's models with 4.0 before building other things or even creating a streamlined build environment since Netty is used as infrastructure by Vertx. From the more flexible thread allocation model to a much better channel organization and state definitions, there are many changes which could be exploited to allign Vertx with its plumbing. In our application we will be, additionally,  using Vertx as the programming environment but still using certain native Netty channels. So, for us it is "doubly  better" to allign then build on. gopi

[Tim Fox]

On 21/11/12 17:08, bytor99999 wrote:
> OK, I agree with all the things considered. Especially the callback
> spaghetti. But probably most important to me, and the #1 issues I
> would like to see in vert.x and it has to be unobstrusive (which is
> the tricky part) And that is 100% easy integration with the Spring
> Framework. A simple way to create an ApplicationContext and have
> access to it in any verticle. But either have only one instance of it
> per verticle, or per vert.x application.
>
> I am tired of have to architect fully to so many callback spaghetti
> and write so much more code in vert.x that I could have so easily and
> quickly done with Spring. Accessing data with Spring data. Setting up
> an easier control flow with Spring Integration. But instead of taking
> days, it will take weeks/months to write the same code without Spring.

Well.. Vert.x is a much lower level tool than Spring Integration/Spring
Data. I'd envision that as we go ahead someone will write modules in
Vert.x that perhaps solve the same problem that Spring Integration/
Spring data does.

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/4I6f94nMTzQJ.

[Steven Holmes]

Please, please, please don't go to maven.  I've used Maven for years and have been using gradle in anger for about 9 months.  I am already so much more able to get things done on large projects with Gradle than with Maven.  I've been working on the Kotlin contribution to Vert.x and I will agree that there are some problems with the build but they are implementation issues and not issues with the build system.  In my experience Maven is extremely inflexible and not pragmatic for an integration build of many different projects, which is exactly what vert.x is.  I've spent too much of my life as a programmer trying to work around Maven's inflexible nature.  For my part, I would never have even considered contributing if the build was using maven.

[Pid]

On 21/11/2012 16:30, Brian Lalor wrote:
> On Nov 21, 2012, at 9:39 AM, Pid <p...@pidster.com> wrote:
>
>>> Let's reuse the tools people are used-to and lets make it dead
>>> simple for them to help us improve Vertx. In others words lets migrate
>>> the build system from Gradle to Maven, it should only take a couple of
>>> hours. It will also help with you second item 'IDE integration' since
>>> Maven is nicely integrated with the major IDEs
>>
>> It's already been shown that it took longer to assemble a working Maven
>> build for vert.x.
>
> Could you explain, please? Are you talking execution time? I do see that Gradle is faster, but I think we're talking 60s vs 120s with Maven.
>
> I already ported the build to Maven once and I'd jump at the opportunity to do it again. It was easy, and the benefit to others wanting to jump in would be huge. I'm extremely reluctant to develop on the Vert.x core because the Gradle build is a nightmare to comprehend. Maven has its flaws, but it has a huge mindshare and once you learn it once, you know it for all projects. It appears that every Gradle build is the developer's invention, like the Bad Old Days of ant.

With respect, I thought you ported the Gradle build to Maven - having
the advantage that it had already been restructured. I think an earlier
attempt was made. Is my recollection correct?*


People can still work with the core code to extend or patch it without
needing to know Gradle. This argument is entirely orthogonal to their
ability to contribute changes or additions to the codebase IMO.

We could provide a better explanation of the build and how people could
contribute, yes, but one might equally argue that if the choice of build
language prevents someone from contributing a patch or some code
changes, then a Maven-based build is equally likely to be a source of
friction.

> Also, the Maven build I created didn't require any environment setup at all. Jython, JRuby,etc were set up as dependencies for the build process. Today you have to download and install them yourself. With the maven build, you clone the repo and run "mvn package" and you're done. No thought required.

I had a version that did that too, but this wasn't accepted - and it's
certainly achievable independently of the build language/tool.


p


* I may not, but the archives will show the truth!


--

[key:62590808]

[Pid]

On 21/11/2012 17:08, bytor99999 wrote:
> OK, I agree with all the things considered. Especially the callback
> spaghetti. But probably most important to me, and the #1 issues I would
> like to see in vert.x and it has to be unobstrusive (which is the tricky
> part) And that is 100% easy integration with the Spring Framework. A
> simple way to create an ApplicationContext and have access to it in any
> verticle. But either have only one instance of it per verticle, or per
> vert.x application.

As you know, I'm really interested in this too - partly because I think
it touches a few different problems for vert.x, but partly because it
opens up access to rich ecosystem for enterprise developers.

> I am tired of have to architect fully to so many callback spaghetti and
> write so much more code in vert.x that I could have so easily and
> quickly done with Spring. Accessing data with Spring data. Setting up an
> easier control flow with Spring Integration. But instead of taking days,
> it will take weeks/months to write the same code without Spring.
>
> I know I have brought this up too many times, but I really think this
> would open up the flood gates for a lot more people to start using vert.x

I've done some work on this front, did you try it out?


p

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/vertx/-/4I6f94nMTzQJ.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.


--

[key:62590808]

[bytor99999]

I would hate for someone to re-invent the wheel, and it is an extremely big wheel or wheels to re-invent. It would probably be much easier to integrate with Spring. Especially on those two projects which are amazing and work incredibly well. There is nothing out there like Spring Data. Well, probably you could say GORM.

And many people would also want to leverage all the knowledge they already have with Spring into our vert.x projects.

I don't consider vert.x to be a lower level, just a different environment/model/architecture to deploy/write your applications.

I have to be honest, there are a lot of places in our app where if I had had Spring, I would be done, and I am getting a bit frustrated having to re-code all that from scratch, to where there are some times (rarely) where I feel like not using vert.x and change it to a complete Spring solution would make things easier on the development side, but more difficult on the production, running, scaling side of things. It would require a lot more servers with a Spring solution alone and worries on traffic that I wouldn't have with vert.x alone. I just think that the two working together will allow for much more complex and better applications and a better solution. But I could be wrong, I have been known to be wrong on many occasions.

Please. Thanks

Mark

[Daryl Teo]

jumping in with my 2 pence.

I think all this talk about "brand new this brand new that" is silly. I already have a mostly working implementation that uses a java port of handlebars to handle my templating. I am planning to release this as a module sometime soon.

IMHO a framework like MVC.NET or Play! is not appropriate for a distributed architecture nor is it compatible with the event loop model... not unless you're making serious assumptions about how people will build their web applications: your model would need to make assumptions about how you're storing your data (rdbms/nosql) to handle the persistence and would require direct access to the database. Even assuming all that, you're losing all the advantages of the vertx platform: why use eventbus? why use work modules or work queues? 

May as well just embed vertx into Play!.

This work shouldn't be done on core. People should have the choice to pick what they wish to use. The issues that Tim has picked up are perfect; they have a direct impact on how everyone uses the core platform. Things like an MVC framework? Let's not bother Tim with it.

Next: one of the issues of a polyglot platform is that there is an incompatibility between each language supported by the platform, and compatibility layers need to be constructed to ensure similar operations on each. Sometimes, things need to be compromised: like type safety. One need only look to the eventbus mechanism to see how type-safety has already been compromised (JsonObject). You can't have your cake and eat it too, I don't think.

Daryl 

[bytor99999]

Unfortunately, when I first checked it out I was too early in my vert.x learning experience and couldn't figure out what I needed to do to use your module. I will check it out again.

Yes, open up access to many developers out there is a good thing to promote vert.x.

Mark

On Wednesday, November 21, 2012 1:34:44 PM UTC-8, Pid wrote:

As you know, I'm really interested in this too - partly because I think
it touches a few different problems for vert.x, but partly because it
opens up access to rich ecosystem for enterprise developers.

[Fabrice Sznajderman]

Hello,

+1 All is great!

I have a question regarding the following sentence : Other issues include not being able to put user defined classes in a Shared map and share them between module instances.

This  means, in the next release, that Share map should accepted classes defined by user? In other word, all verticles should  share instances from user's classes?

This will be possible with classloader refactoring that you  planned?

Regards

--
Fabrice SZNAJDERMAN
photographie : http://photos.fsznajderman.fr
blog : http://blog.fsznajderman.fr

twitter : fsznajderman

G+ : http://gplus.to/fsznajderman

Rédacteur sur Java - ʕ๏̮๏ʔ

[bytor99999]

I am glad you brought that up and that I had just glossed over it. 

One feature that would be great is being able to use the SharedData across the cluster between many instance of vert.x running in that cluster.

Mark

[A B]

Hi Tim,

Maybe this is obvious, but I have not figured it out. Can you deploy vert.x on a mobile device? So, write the client in javascript on a mobile device which talks through the event bus with the vert.x server? I mean that the client loads the vert.x javascript on the device, not from a server location.

Best regards, Bart

[Tim Fox]

On 21/11/12 16:34, Tim Yates wrote:
> See, I'm the exact opposite, avoid maven wherever possible and find
> Gradle to be much nicer...

I see Maven vs Gradle as primarily a religious issue.

>
> Tim
>
>
>
> On 21 November 2012 16:30, Brian Lalor <bla...@bravo5.org

> <mailto:bla...@bravo5.org>> wrote:
>
>
> Could you explain, please? Are you talking execution time? I do
> see that Gradle is faster, but I think we're talking 60s vs 120s
> with Maven.
>
> I already ported the build to Maven once and I'd jump at the
> opportunity to do it again. It was easy, and the benefit to
> others wanting to jump in would be huge. I'm extremely reluctant
> to develop on the Vert.x core because the Gradle build is a
> nightmare to comprehend. Maven has its flaws, but it has a huge
> mindshare and once you learn it once, you know it for all
> projects. It appears that every Gradle build is the developer's
> invention, like the Bad Old Days of ant.
>
> Also, the Maven build I created didn't require any environment
> setup at all. Jython, JRuby,etc were set up as dependencies for
> the build process. Today you have to download and install them
> yourself. With the maven build, you clone the repo and run "mvn
> package" and you're done. No thought required.
>
> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To post to this group, send an email to ve...@googlegroups.com

> <mailto:ve...@googlegroups.com>.

> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com

> <mailto:vertx%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.

[Tim Fox]

On 21/11/12 23:19, bytor99999 wrote:
> I would hate for someone to re-invent the wheel, and it is an
> extremely big wheel or wheels to re-invent. It would probably be much
> easier to integrate with Spring. Especially on those two projects
> which are amazing and work incredibly well. There is nothing out there
> like Spring Data. Well, probably you could say GORM.
>
> And many people would also want to leverage all the knowledge they
> already have with Spring into our vert.x projects.
>
> I don't consider vert.x to be a lower level, just a different
> environment/model/architecture to deploy/write your applications.
>
> I have to be honest, there are a lot of places in our app where if I
> had had Spring, I would be done, and I am getting a bit frustrated
> having to re-code all that from scratch, to where there are some times
> (rarely) where I feel like not using vert.x and change it to a
> complete Spring solution would make things easier on the development
> side, but more difficult on the production, running, scaling side of
> things.

If Spring works for you and can handle your traffic then use it.

I don't know enough about Spring to know whether this is true or not,
but if it uses a primarily synchronous approach (and doesn't use
continuations) then it's going to have scalability issues when you have
a lot of connections.

This might not be an issue to you depending on how much traffic you
expect, but on the other hand it might. How long is a piece of string?

We could indeed create an adaptor that allows you to talk to Spring, and
I'm sure that would be useful for a lot of users, and it's definitely
worth doing. But if you just pump all your Vert.x traffic through Spring
code that's using a blocking approach, then that might well prove to be
your bottleneck - i.e. you lose the scalability advantages of Vert.x

If you want to cope with many (millions?) of concurrent connections (and
I'm betting this is the future - websockets/mqtt etc) then a non
blocking approach is essential.

So eventually, we may have to provide things with nice APIs that do
things like Spring, but in an async way. No alternative to rewriting the
wheel there, if you want it to scale. I would think of it more like
improving the wheel though.

If I manage to get a direct style api working in Vert.x using
continuations (this is what I'm researching now) then you'll be able to
use familiar direct style (synchronous) apis that DO scale - i.e. have
your cake and eat it.

> <https://groups.google.com/d/msg/vertx/-/4I6f94nMTzQJ>.

> > To post to this group, send an email to ve...@googlegroups.com

> <javascript:>.

> > To unsubscribe from this group, send email to

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

> > For more options, visit this group at
> > http://groups.google.com/group/vertx?hl=en-GB

> <http://groups.google.com/group/vertx?hl=en-GB>.

>
>
> --
> Tim Fox
>
> Vert.x - effortless polyglot asynchronous application development
> http://vertx.io
> twitter:@timfox
>

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/7iV_GZ81NOYJ.

[Tim Fox]

On 21/11/12 23:31, Fabrice Sznajderman wrote:
> Hello,
>
> +1 All is great!
>

> I have a question regarding the following sentence : *Other issues

> include not being able to put user defined classes in a Shared map and

> share them between module instances.*

>
> This means, in the next release, that Share map should accepted
> classes defined by user? In other word, all verticles should share
> instances from user's classes?

yes

> <mailto:ve...@googlegroups.com>.

> > To unsubscribe from this group, send email to
> > vertx+un...@googlegroups.com

> <mailto:vertx%2Bunsu...@googlegroups.com>.

> > For more options, visit this group at
> > http://groups.google.com/group/vertx?hl=en-GB.
>
>
> --
>
> [key:62590808]
>
>
>
>
> --
> Fabrice SZNAJDERMAN
> photographie : http://photos.fsznajderman.fr

> blog : http://blog.fsznajderman.fr <http://sznajderman.developpez.com>

> twitter : fsznajderman
> G+ : http://gplus.to/fsznajderman
> Rédacteur sur Java - ʕ๏̮๏ʔ

> <https://plus.google.com/u/0/b/112440333946538821016/>

>
> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.

> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.


--

[Tim Fox]

On 21/11/12 23:43, bytor99999 wrote:
> I am glad you brought that up and that I had just glossed over it.
>
> One feature that would be great is being able to use the SharedData
> across the cluster between many instance of vert.x running in that
> cluster.

Ah yes, I forgot about that.

Perhaps we should add it to the list too.

>
> Mark
>
> On Wednesday, November 21, 2012 3:31:24 PM UTC-8, Fabrice Sznajderman
> wrote:
>
> Hello,
>
> +1 All is great!
>

> I have a question regarding the following sentence : *Other issues

> include not being able to put user defined classes in a Shared map

> and share them between module instances.*

> <https://groups.google.com/d/msg/vertx/-/4I6f94nMTzQJ>.

> > To post to this group, send an email to

> ve...@googlegroups.com <javascript:>.

> > To unsubscribe from this group, send email to

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

> > For more options, visit this group at
> > http://groups.google.com/group/vertx?hl=en-GB

> <http://groups.google.com/group/vertx?hl=en-GB>.

>
>
> --
>
> [key:62590808]
>
>
>
>
> --
> Fabrice SZNAJDERMAN
> photographie : http://photos.fsznajderman.fr

> blog : http://blog.fsznajderman.fr <http://sznajderman.developpez.com>

> twitter : fsznajderman
> G+ : http://gplus.to/fsznajderman
> Rédacteur sur Java - ʕ๏̮๏ʔ

> <https://plus.google.com/u/0/b/112440333946538821016/>

>
> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/kzyjbXh-ri8J.

> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.


--

[Tim Fox]

On 22/11/12 06:39, A B wrote:
> Hi Tim,
>
> Maybe this is obvious, but I have not figured it out. Can you deploy
> vert.x on a mobile device? So, write the client in javascript on a
> mobile device which talks through the event bus with the vert.x
> server? I mean that the client loads the vert.x javascript on the
> device, not from a server location.

I'm not entirely sure what you mean here. Do you mean can a browser on a
mobile device load some JavaScript from a local path?

I'm not sure, but browsers normally have the ability to load any
resources from the local filesystem.

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/fO8DYkHw6y8J.

[Paulo Lopes]

What about implement a plugable serialization to the eventBus to allow other than JSON?

In my oppinion it makes sense in the following scenario:

A aggregation of news sources that are rendered as json/xml/whatever format given the client accept-encoding header.

1 A user makes a request with accept header to application/json
2 The main verticle publishes a request for all news into the eventBus
3 the worker clients will fetch data from several sources (e.g.):
 * rss xml feeds
 * local database (relational)
 * local database (nosql)
4 the workers return the results to the main verticle
5 the main verticle formats to the right format

Since the curren eventBus is only JSON at step 5 data types that are common in databases
* Date/Timestamp
* Long
* Decimal/Integer
* etc...

the main verticle would now need to have knowledge on the schema of the data in order to proper serialize it to the client.

The same would happen if the use case was:

"An aggregator of news to be queries by date"

1 News sources push news to a central news repository
2 the main verticle would receive the data
 * xml
 * json
 * txt
3 the main verticle would publish a those messages to the storage worker
 * the news would be converted to json, dates would be converted to text as well any other types which do not have a JSON mapping
4 the worker stores the news into a database

At point 3 we would loose information by conversion
At point 4 we would need to do more conversions back from text to date if we would want to keep the database searchable by date


These are just trivial examples, it would be easier to come up with more. All i am saying is that it would be nice if one could configure the type of serialized data in the eventBus.
I would not expect to have multiple implementations, all i would like to have is the possibility to override JSON with my prefered one by configuring vert.x by supplying a jar file with a message implementation of my choice.

[Tim Fox]

The event bus has always supported multiple types on the server side,
using JSON is just a convention for the sake of interoperability.

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/WYW6zhdtKs0J.

[Paulo Lopes]

Maybe it would be a bit outside the scope but are you considering a native event bus implementation say for android or ios?

For example android developers would add a jar with the vert.x eventbus to their project and they could receive/send messages to a vert.x node.

[christiank]

Hi all,

I've had some success integrating vert.x with spring for dependency injection. Next on my list of experiments is seeing how easily I can add JAX-RS to the mix by integrating jersey.

If I would have a list of things to be officially added they would be:
1. JAX-RS support (jersey integration), I'd even prefer this to standard MVC
2. Some kind of DI by adding guice or spring support.

Cheers,

Christian

[Paulo Lopes]

Yes i see from the javadocs that is supports:

Boolean

Buffer

Byte

byte[]

Character

Double

Float

Integer

JsonArray

JsonObject

Long

Short

String

I would like to have the chance to use something else like T<? extends Serializable> the rationale behind this is that i don't want to care about serialization in my code (since it is not a real concern of my application) but want to have more freedom that the JsonObject/JsonArray

Anyway it was just my 2cts

[Christian Essl]

I think this two helper enable to send Serilizable over the eventbus.

public static Buffer toBuffer(Object s) {

    ByteArrayOutputStream bo = new ByteArrayOutputStream();

    ObjectOutputStream os = new ObjectOutputStream(bo);

    os.writeObject(s);

    os.close();

    return new Buffer(bo.toByteArray());

    }catch (Exceptione x) {

       throw new RuntimeException(x);

    }

}

public static Object fromBytes(Buffer bs) {

    try {

    return (new ObjectInputStream(new ByteArrayInputStream(bs.getBytes())).readObject();

    }catch (Exceptione x) {

       throw new RuntimeException(x);

    }

}

//usage

eventbus.send(address,toBuffer(myObject));

eventbus.registerHandler(address, new Handler<Message<Buffer>>() {

     public void handle(Message<Buffer> msg) {

         MyObject o = (MyObject) fromBytes(msg.body);

     }

});

[Tim Fox]

True, but Java serialization is horribly slow.

> <https://groups.google.com/d/msg/vertx/-/WYW6zhdtKs0J>.

> > To post to this group, send an email to ve...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > vertx+un...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/vertx?hl=en-GB

> <http://groups.google.com/group/vertx?hl=en-GB>.

>
>
> --
> Tim Fox
>
> Vert.x - effortless polyglot asynchronous application development
> http://vertx.io
> twitter:@timfox
>

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/wXjjDARc-B8J.

[A B]

Hi Tim,

I mean a "native" implementation such as for example phonegap does. So, the javascript resources including vertxbus.js are loaded on the mobile device from within an App. Should this work? I noticed on iOS that only when you load remote javascript using UIWebView that it works. With local html file load in UIWebView is does not due to the fact that vertxbus.js uses this:

(function DemoViewModel() {

  var that = this;
  var eb = new vertx.EventBus(window.location.protocol + '//' + window.location.hostname + ':' + window.location.port + '/eventbus');

And window.location.protocol work only in a browser, not native using load HTML code -->

[Web loadRequest:[NSURLRequest requestWithURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"index" ofType:@"html"]isDirectory:NO]]];

I guess it is implemented to work in a client browser only?

Best regards, Bart

[Tim Fox]

On 22/11/12 11:11, A B wrote:
> Hi Tim,
>

> I mean a "native" implementation such as for example phonegap does.
> So, the javascript resources including vertxbus.js are loaded on the
> mobile device from within an App. Should this work? I noticed on iOS
> that only when you load remote javascript using UIWebView that it
> works. With local html file load in UIWebView is does not due to the
> fact that vertxbus.js uses this:
>
> (function DemoViewModel() {
> var that = this;
> var eb = new vertx.EventBus(window.location.protocol + '//' +
> window.location.hostname + ':' + window.location.port + '/eventbus');
> And window.location.protocol work only in a browser, not native using
> load HTML code -->
> |[Web loadRequest:[NSURLRequest requestWithURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"index" ofType:@"html"]isDirectory:NO]]];|
> I guess it is implemented to work in a client browser only?

That code is not from vertxbus.js, it's from an example that uses
vertxbus.js

The constructor parameter to EventBus is just the URL you're pointing
the client at. So just point it at wherever your server is.

> <https://groups.google.com/d/msg/vertx/-/fO8DYkHw6y8J>.

> > To post to this group, send an email to ve...@googlegroups.com

> <javascript:>.

> > To unsubscribe from this group, send email to

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

> > For more options, visit this group at
> > http://groups.google.com/group/vertx?hl=en-GB

> <http://groups.google.com/group/vertx?hl=en-GB>.

>
>
> --
> Tim Fox
>
> Vert.x - effortless polyglot asynchronous application development
> http://vertx.io
> twitter:@timfox
>

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/J93QAICTlB8J.

[Paulo Lopes]

Yes that is a valid point, it is slow, however one could use something else like bson, protocol buffers, tlv, etc that is why i was sugesting a possible way to make it like a plugin that developers could implement with their favourite serialization format.

What i like in that appoach is that i don't add serialization and deserialization code all over in the application but just enable a plugin...

[Christian Essl]

I do have a similar problem in yeti support: I always have to convert from yeti structs to JSONObject (which is expensive) also the copying is unecessery because the the yeti struct is immutable anyway.

Maybe the bus could recognize an Interface:

interface BusWrapper {

   public Object getValue(); //get the original unmodified object (or a copy of it)

   public byte[] serialize(); //for network

   public Object getBasicType(); //returns one of JSONObject, String, Buffer etc for language interroperaiblity

[Tim Fox]

On 22/11/12 11:15, Paulo Lopes wrote:
> Yes that is a valid point, it is slow, however one could use something
> else like bson, protocol buffers, tlv, etc that is why i was sugesting
> a possible way to make it like a plugin that developers could
> implement with their favourite serialization format.
>
> What i like in that appoach is that i don't add serialization and
> deserialization code all over in the application but just enable a
> plugin...

You could easily wrap the event bus object with a wrapper which does the
conversion from BSON (or whatever) to Buffer and back again.

> <https://groups.google.com/d/msg/vertx/-/wXjjDARc-B8J>.

> > To post to this group, send an email to ve...@googlegroups.com

> <javascript:>.

> > To unsubscribe from this group, send email to

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

> > For more options, visit this group at
> > http://groups.google.com/group/vertx?hl=en-GB
> <http://groups.google.com/group/vertx?hl=en-GB>.
>
>
> --
> Tim Fox
>
> Vert.x - effortless polyglot asynchronous application development
> http://vertx.io
> twitter:@timfox
>
> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/qtIMoBuGMO0J.

[Tim Fox]

On 22/11/12 11:20, Tim Fox wrote:
> On 22/11/12 11:15, Paulo Lopes wrote:
>> Yes that is a valid point, it is slow, however one could use
>> something else like bson, protocol buffers, tlv, etc that is why i
>> was sugesting a possible way to make it like a plugin that developers
>> could implement with their favourite serialization format.
>>
>> What i like in that appoach is that i don't add serialization and
>> deserialization code all over in the application but just enable a
>> plugin...
> You could easily wrap the event bus object with a wrapper which does
> the conversion from BSON (or whatever) to Buffer and back again.

Actually, this is exactly the kind of thing that would be good to put in
a module.

Just create a simple module which contains a wrapper class for the
eventbus which does the BSON encoding/decoding.

Put it in the public repo.

Then if someone wants a BSON-enabled event bus they just do

include "org.foo.BSONEventBus-v1.0" (in mod.json)

And in code, get a ref to the BSON eventbus with something like:

BsonEventBus beventbus = BSonEventBus.instance (or whatever)

[Jettro Coenradie]

I like your point 5, projections. I did some reading and found this nice JavaScript based framework called Q:

https://github.com/kriskowal/q

regards Jettro

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/vertx/-/tkgy0Xgyq_gJ.

To post to this group, send an email to ve...@googlegroups.com.
To unsubscribe from this group, send email to vertx+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/vertx?hl=en-GB.

--
Jettro Coenradie
http://www.gridshore.nl

[Brian Lalor]

On Nov 22, 2012, at 8:29 AM, Jettro Coenradie <jettro.c...@gridshore.nl> wrote:

I like your point 5, projections. I did some reading and found this nice JavaScript based framework called Q:

https://github.com/kriskowal/q

That looks interesting.  I've been using async[1] in both client and server code for a few months and find it pretty much perfect.

[1]: https://github.com/caolan/async

[Toshihiro Shimizu]

I want TypeScript support.

Toshihiro Shimizu / @meso

[Pid *]

On 22 Nov 2012, at 09:43, Paulo Lopes <pml...@gmail.com> wrote:

What about implement a plugable serialization to the eventBus to allow other than JSON?

There already is. Serialize your object and send it as byte[].

p

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/vertx/-/WYW6zhdtKs0J.

[Pid *]

Knock yourself out. ;)

[bytor99999]

"I don't know enough about Spring to know whether this is true or not, 
but if it uses a primarily synchronous approach (and doesn't use 
continuations) then it's going to have scalability issues when you have 
a lot of connections. "

Unfortunately, that is the issue. Because what you know or don't know about Spring makes you look at it in a wrong way. Spring itself is neither synchronous or asynchronous. Spring isn't about one approach or another. There is a lot to Spring and my big need is that no matter what, I have some database calls, some messaging to AMQP, and Spring Data and Spring Integration is the simplest approach, smallest amount of code. Why should I write thousands of lines of code, that I can get for say one hundred of code or config. It is code I would have had to write with vert.x worker verticle no matter what is in my application, and I can say probably in the majority of vert.x applications that will be written.

A big key of Spring is write POJOs and focus on your domain of what you need. All the boilerplate code is hidden from the developer having to write.

I have thought of a simple solution that can work. I can start up Spring ApplicationContext once in the App script, in that script deploys the verticles. If in the deploy method I could pass and Object[] of objects that each verticle instance has reference to. Maybe it automatically puts those objects into SharedData, but maybe a built in method to ask for that object in the verticle.

Mark

[bytor99999]

But don't get me wrong. I don't mean all this is a mean or bad or angry way. I have great respect for this project and Tim. One of the great things about Tim, is while he has his opinions, he is still quite open to many ideas. For instance, his willingness to allow us to help vote for the build mechanism.

I have an idea for integrating Spring, but it will require that we either use a static field in a class, or that SharedData allows other types (which I believe is a point to add to 2.0, in the list above)

I am going to post my ideas in a different thread.

Mark

[Joris Hermans]

I think a lot of people are using Maven, honestly I never heard of Gradle before!

So having also a maven plugin in place would be nice, maybe support both of them.

[Joris Hermans]

Pid, I want to help you with the management ui, I am a web developer and it would be great if I can could of help with building the css, js and html for the management ui.

Let me know what I can do!

Joris

[Harry2010]

Tim,

Have you had time to reconsider upping the priority of moving to Netty 4.0 gopi

[Tim Fox]

On 23/11/2012 16:31, Harry2010 wrote:

Tim,

Have you had time to reconsider upping the priority of moving to Netty 4.0 gopi

I know Norman from the Netty team has been looking at this already, so maybe we will get this done before 2.0

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/vertx/-/2VT0pcitqsUJ.

[Fabrice Sznajderman]

Hi Tim,

Thanks for your answer!

On Thu, Nov 22, 2012 at 10:24 AM, Tim Fox <timv...@gmail.com> wrote:

On 21/11/12 23:31, Fabrice Sznajderman wrote:

Hello,

+1 All is great!

I have a question regarding the following sentence : *Other issues include not being able to put user defined classes in a Shared map and share them between module instances.*

This  means, in the next release, that Share map should accepted classes defined by user? In other word, all verticles should  share instances from user's classes?

yes

This will be possible with classloader refactoring that you  planned?

Regards

On Wed, Nov 21, 2012 at 10:34 PM, Pid <p...@pidster.com <mailto:p...@pidster.com>> wrote:

    On 21/11/2012 17:08, bytor99999 wrote:
    > OK, I agree with all the things considered. Especially the callback
    > spaghetti. But probably most important to me, and the #1 issues
    I would
    > like to see in vert.x and it has to be unobstrusive (which is
    the tricky
    > part) And that is 100% easy integration with the Spring Framework. A
    > simple way to create an ApplicationContext and have access to it
    in any
    > verticle. But either have only one instance of it per verticle,
    or per
    > vert.x application.

    As you know, I'm really interested in this too - partly because I
    think
    it touches a few different problems for vert.x, but partly because it
    opens up access to rich ecosystem for enterprise developers.


    > I am tired of have to architect fully to so many callback
    spaghetti and
    > write so much more code in vert.x that I could have so easily and
    > quickly done with Spring. Accessing data with Spring data.
    Setting up an
    > easier control flow with Spring Integration. But instead of
    taking days,
    > it will take weeks/months to write the same code without Spring.
    >
    > I know I have brought this up too many times, but I really think
    this
    > would open up the flood gates for a lot more people to start
    using vert.x

    I've done some work on this front, did you try it out?


    p


    > Thanks
    >
    > Mark

    > https://groups.google.com/d/msg/vertx/-/4I6f94nMTzQJ.

    > To post to this group, send an email to ve...@googlegroups.com

    <mailto:ve...@googlegroups.com>.

    > To unsubscribe from this group, send email to

    > vertx+unsubscribe@googlegroups.com

    <mailto:vertx%2Bunsubscribe@googlegroups.com>.

    > For more options, visit this group at
    > http://groups.google.com/group/vertx?hl=en-GB.

    --

    [key:62590808]




--
Fabrice SZNAJDERMAN
photographie : http://photos.fsznajderman.fr

blog : http://blog.fsznajderman.fr <http://sznajderman.developpez.com>

twitter : fsznajderman
G+ : http://gplus.to/fsznajderman

Rédacteur sur Java - ʕ๏̮๏ʔ <https://plus.google.com/u/0/b/112440333946538821016/>

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To post to this group, send an email to ve...@googlegroups.com.

To unsubscribe from this group, send email to vertx+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/vertx?hl=en-GB.

--

Tim Fox

Vert.x - effortless polyglot asynchronous application development
http://vertx.io
twitter:@timfox

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To post to this group, send an email to ve...@googlegroups.com.

To unsubscribe from this group, send email to vertx+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/vertx?hl=en-GB.

--
Fabrice SZNAJDERMAN
photographie : http://photos.fsznajderman.fr
blog : http://blog.fsznajderman.fr

twitter : fsznajderman

G+ : http://gplus.to/fsznajderman

Rédacteur sur Java - ʕ๏̮๏ʔ

[Harry2010]

Tim,

Thank you for the reply. I am looking forward to 2.0. We are expecting to build out our communications platform on it. We are actively looking for pat-time and full-time Vertx knowledgeable developers. It has been difficult to find them. I will appreciate any help, where to post for people, intros, etc.. I am even ready to start up a site for vertx learning so we can create a pool of developers. If you can help in identifying experts who can seed such a site with training material I can hire resources to set up such a site. gopi

[Brian Lalor]

On Nov 21, 2012, at 8:12 AM, Tim Fox <timv...@gmail.com> wrote:

> We need an effortless way of easily testing Vert.x verticles/modules from within an IDE. I'm guessing we need an Eclipse + IntelliJ plugin here.

I think the ability to write good unit and integration tests is critical. More than doing them in an IDE, however, I think we need a summary of the tools available to vert.x app developers. Unit testing java verticles shouldn't be too difficult (although the callback-oriented nature does make this a pain), but integration testing them is sort of a black art right now. We really need a way to shut down an embedded instance. Anyway, I guess my point is this: get the build tools sorted in a principle-of-least-surprise way, build on existing testing frameworks with good mindshare, and I think everyone wins.

Along those lines, is there a vert.x wiki? This is the kind of stuff that gets discussed on the mailing list and then forgotten. :-)

[Brian Lalor]

Another thing that would be nice to see for vert.x 2.0 would be the ability to use the asynchronous API methods inside a worker verticle. Maybe this can't be done until the async hell problem is solved, but it would make for more consistent code. From a developer's perspective, it'll seem strange to have two completely different methods of making rest calls if you have an application that does so from a worker and a non-worker verticle.

[Brian Lalor]

On Nov 21, 2012, at 9:39 AM, Pid <p...@pidster.com> wrote:

> The current build /could/ be more simple; extracting the languages as
> modules and localising the tests to each subproject will do much of the
> work.

Build system aside, I think this will be a huge win. It's difficult figure out how to write new tests for one of the core modules when its tests are in a completely separate location. Maven or gradle, I think the standard src/{main,test}/{$LANG,resources}/tld/domain/package directory structure should be applied, with tests living as close to their counterparts as possible.

[Brian Lalor]

On Nov 21, 2012, at 4:30 PM, Pid <p...@pidster.com> wrote:

>> I already ported the build to Maven once and I'd jump at the opportunity to do it again. It was easy, and the benefit to others wanting to jump in would be huge. I'm extremely reluctant to develop on the Vert.x core because the Gradle build is a nightmare to comprehend. Maven has its flaws, but it has a huge mindshare and once you learn it once, you know it for all projects. It appears that every Gradle build is the developer's invention, like the Bad Old Days of ant.
>
> With respect, I thought you ported the Gradle build to Maven - having
> the advantage that it had already been restructured. I think an earlier
> attempt was made. Is my recollection correct?*

The restructuring you did made this very easy. I wouldn't have attempted it otherwise. :-)

> People can still work with the core code to extend or patch it without
> needing to know Gradle. This argument is entirely orthogonal to their
> ability to contribute changes or additions to the codebase IMO.

I disagree. Maybe it's just because of how the tests are in a completely separate module, but having to build the entire project from the root to run one test or see if a test compiles is a major turnoff. Everybody who's ever used maven knows how to do this. The gradle build for vert.x is different. I can live with different if its documented how to do the most common tasks without headaches.

> We could provide a better explanation of the build and how people could
> contribute, yes, but one might equally argue that if the choice of build
> language prevents someone from contributing a patch or some code
> changes, then a Maven-based build is equally likely to be a source of
> friction.

For all its flaws, maven is consistent. You learn how to use (or in some cases hate!) it once, and you know how every other project based on maven works. That's convention over configuration. I won't lobby for a build tool nobody wants, but for me this is again a principle-of-least-surprise thing. We've wasted a tremendous amount of energy (and probably some good will) on this topic. If we can create a $VERTX_BUILD_TOOL to maven Rosetta Stone we'll reduce the barrier to entry for most people and probably have a better build system for vert.x because of it.

[Brian Lalor]

On Nov 22, 2012, at 5:06 AM, Paulo Lopes <pml...@gmail.com> wrote:

> I would like to have the chance to use something else like T<? extends Serializable> the rationale behind this is that i don't want to care about serialization in my code (since it is not a real concern

If you could put Serializable objects into messages on the eventbus that would be a huge win.

[Brian Lalor]

On Nov 22, 2012, at 5:53 AM, Tim Fox <timv...@gmail.com> wrote:

> True, but Java serialization is horribly slow.

But it's a useful tool. I wouldn't have to replace what's in place today, just augment it. You could make it clear to the users the performance implications, but I don't think vert.x should be so opinionated as to exclude that as an option.

[Pid]

On 25/11/2012 12:23, Brian Lalor wrote:
>
> On Nov 21, 2012, at 4:30 PM, Pid <p...@pidster.com> wrote:
>
>>> I already ported the build to Maven once and I'd jump at the opportunity to do it again. It was easy, and the benefit to others wanting to jump in would be huge. I'm extremely reluctant to develop on the Vert.x core because the Gradle build is a nightmare to comprehend. Maven has its flaws, but it has a huge mindshare and once you learn it once, you know it for all projects. It appears that every Gradle build is the developer's invention, like the Bad Old Days of ant.
>>
>> With respect, I thought you ported the Gradle build to Maven - having
>> the advantage that it had already been restructured. I think an earlier
>> attempt was made. Is my recollection correct?*
>
> The restructuring you did made this very easy. I wouldn't have attempted it otherwise. :-)
>
>> People can still work with the core code to extend or patch it without
>> needing to know Gradle. This argument is entirely orthogonal to their
>> ability to contribute changes or additions to the codebase IMO.
>
> I disagree. Maybe it's just because of how the tests are in a completely separate module, but having to build the entire project from the root to run one test or see if a test compiles is a major turnoff.

I happen to agree that the majority of tests should be in their related
subproject, rather than an external project. It is of course possible
to run a single test, but many of the current tests are integration
tests that require vert.x to built and run.

> Everybody who's ever used maven knows how to do this. The gradle build for vert.x is different.

The layout of the tests isn't anything to do with whether the build uses
Gradle or not. Again, one might also argue the same for Gradle.

> I can live with different if its documented how to do the most common tasks without headaches.

Which tasks? I'm happy to look at the build documentation if there's
something that can be improved.

>> We could provide a better explanation of the build and how people could
>> contribute, yes, but one might equally argue that if the choice of build
>> language prevents someone from contributing a patch or some code
>> changes, then a Maven-based build is equally likely to be a source of
>> friction.
>
> For all its flaws, maven is consistent. You learn how to use (or in some cases hate!) it once, and you know how every other project based on maven works.

I've seen some Maven builds that are extremely difficult to work out.

> That's convention over configuration. I won't lobby for a build tool nobody wants, but for me this is again a principle-of-least-surprise thing. We've wasted a tremendous amount of energy (and probably some good will) on this topic. If we can create a $VERTX_BUILD_TOOL to maven Rosetta Stone we'll reduce the barrier to entry for most people and probably have a better build system for vert.x because of it.

Gradle also uses those conventions, it just happens to be more flexible.
It's nothing to do with Gradle that the tests are in a separate project.


p


--

[key:62590808]

[Pid]

What's the difference between you doing serialization and vert.x doing it?


p


--

[key:62590808]

[Pid]

On 25/11/2012 12:02, Brian Lalor wrote:
> On Nov 21, 2012, at 8:12 AM, Tim Fox <timv...@gmail.com> wrote:
>
>> We need an effortless way of easily testing Vert.x verticles/modules from within an IDE. I'm guessing we need an Eclipse + IntelliJ plugin here.

The classpath thing is the trickiest bit. I've had a few conversations
about an Eclipse plugin.

> I think the ability to write good unit and integration tests is critical. More than doing them in an IDE, however, I think we need a summary of the tools available to vert.x app developers. Unit testing java verticles shouldn't be too difficult (although the callback-oriented nature does make this a pain), but integration testing them is sort of a black art right now. We really need a way to shut down an embedded instance. Anyway, I guess my point is this: get the build tools sorted in a principle-of-least-surprise way, build on existing testing frameworks with good mindshare, and I think everyone wins.

I have been working on this:

https://github.com/swilliams-vmw/vertx-junit-annotations

Please have a look at the tests in this project - I'd be interested to
hear your feedback.


p

> Along those lines, is there a vert.x wiki? This is the kind of stuff that gets discussed on the mailing list and then forgotten. :-)
>

--

[key:62590808]

[Tim Fox]

+1. It would be trivial to create a wrapper of the Vert.x event bus
which handles the serialization/deserialization for you.

Then make your code use the wrapper instead of the real event bus. If
you like you could contribute this as a module so others could use it.

The same argument applies for BSON/<insert you preferred event bus
formats here>
>
>
> p
>
>

[Markus Günther]

+1 to making better unit/integration test support a priority. 
This is actually the main reason why we don't use vert.x.
Currently (A)TDD is not a realistic option with vert.x, which makes it a non-option for many cases, especially if what is being developed is not just a project but a product which must be maintained for a couple years.
As of today, I have no idea how to do long term qa (especially regression management) on a significant vert.x development effort.

[Peter Ledbrook]

>> I can live with different if its documented how to do the most common tasks without headaches.
>
> Which tasks? I'm happy to look at the build documentation if there's
> something that can be improved.

If this is purely about how to use the build rather than how to
contribute to the build, then I do recommend aligning it with Maven as
much as possible (as long as it doesn't over-complicate the build).
Docs are important, but people's expectations often override those.

I haven't checked the build recently, but does it have 'compile', and
'package' tasks? What about 'integration-test'?

Peter

--
Peter Ledbrook
t: @pledbrook

[Jez P]

I disagree with the assertion that TDD is not a realistic option, I've found it very easy so far to build tests that let you test your vert.x application at any level, including hitting an HTTP server and then putting in small stubs to handle events on the event bus by injecting known responses). These tests are based on JUnit (via TestBase) admittedly, but it was trivial to create a groovy wrapper around TestBase and then write the tests in pretty succinct groovy. Is it perfect? No. Does it preclude TDD? Most definitely not. 

My applications just to learn so far have been pretty small, admittedly, but I'm sure bytor, who's been writing a pretty significant vert.x application, wouldn't have been doing so in other than a test-driven manner. 

[Paulo Lopes]

Hi Tim,

Some feature that is missing for me is when working with Buffers some times i need to generate binary content that needs to be encoded in little endian format, however The buffer constructor has no way to specify the "endianess" of the underlying DynamicChannelBuffer. I then need to manually encode by 16/32/64 bit int/float values or create an extra buffer myself and then append to the vert.x buffer.

If we could have a change in the constructor of the Buffer to allow ByteOrder to be specified than it would reduce the amount of small lived objects one needs to create just to encode binary data. Therefore making both code simpler and faster (by doing less transformations).

Thanks,
Paulo

On Wednesday, November 21, 2012 2:12:01 PM UTC+1, Tim Fox wrote:

During Devoxx I started to think about what we need to do to take Vert.x to the next level. There is currently a lot of interest in Vert.x that we need to build on, but there's also quite a lot we need to do to gain acceptance in the enterprise.

I would therefore like to start working in the next few weeks on the next major release - vert.x 2.0.

Some of the things I'd like to consider including in this release are:

1. Classloader refactoring.

Currently each verticle/module runs in its own classloader instance. The main reason for this is to provide isolation by preventing instances to share data using statics.

However this has problems including permgen getting easily exhausted as each instance has its own copy of classes including copies of classes from any other jars that it uses. This doesn't scale.

Other issues include not being able to put user defined classes in a Shared map and share them between module instances.

I'd therefore like to change the classloading module such that each module/verticle *type* (not instance) has its own classloader instance. This means classes would only be loaded for a module once, not once per instance. This is a more traditional model you'd find in most app servers.

The down side of this is users will be able to share data using static members between instances of the same module/verticle. But I think this is a price worth paying. (We can warn against this).

2. IDE integration.

We need good Eclipse/IntelliJ integration.

Personally I don't use IDEs for anything much more than editing files, but I'm probably in a minority.

We need the Gradle tasks to work properly for creating Eclipse/IntelliJ projects (currently they are broken).

We need an effortless way of easily testing Vert.x verticles/modules from within an IDE. I'm guessing we need an Eclipse + IntelliJ plugin here.

[bytor99999]

On Monday, November 26, 2012 3:06:55 AM UTC-8, Jez P wrote:

My applications just to learn so far have been pretty small, admittedly, but I'm sure bytor, who's been writing a pretty significant vert.x application, wouldn't have been doing so in other than a test-driven manner. 

Wait, does that mean I am using TDD? I wish I was. I do like TDD a lot. But I tend to be lazy. I should be writing more tests, but I haven't taken the time to really learn the vert.x test classes to use. And the main testing that I have written was our message content validation api. I used Spock for that. And in writing that was on non vert.x code. But I really, really should be writing unit tests.

Mark