Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split code into packages/modules #254

Closed
thepratt opened this issue Sep 21, 2015 · 4 comments

Comments

@thepratt
Copy link

commented Sep 21, 2015

Hey everyone,

Just wanted to start this off by saying thanks for Finatra, it's a great solution!

I wanted to know if there was any way (on the roadmap, or currently) to split out routines run by a controller into multiple modules (or similar). For example, if I could have:
com.thepratt.package1
com.thepratt.package2
com.thepratt.core

The above will all have their own controllers to handle requests, and would be able to be included via sbt as separate definitions (if needed, or not).

There is currently a test around a multi-server setup: https://github.com/twitter/finatra/tree/c06713972b1c047288320129c7fb87437eb92085/http/src/test/scala/com/twitter/finatra/http/integration/multiserver Correct me if I'm wrong, but this requires duplication of all routes. So for each route in package1/2, I'd need to recreate it in core or another bridge package.

I hope I was clear enough in what I was asking.

Thanks,

Sam

@cacoco

This comment has been minimized.

Copy link
Member

commented Sep 21, 2015

@thepratt routes are currently only defined within a Controller class, like here. You can put your controllers inside of any package structure you'd like.

A server then defines how you want to compose those controllers with any filters along with defining any modules that provide ways to instantiate classes your controllers need. The server could then be thought of as a collection of routes.

If you want to have multiple servers that express different configurations of controllers, filters, and modules you certainly can do so.

The multi-server test is merely an example of how to go about starting up multiple servers in the same process in order to test interactions between them. It's not meant to be anything other than an example of a way to test multiple servers.

I'm not sure if that answers your question or not. If you are specifically asking about supporting adding/defining routes outside of a Controller class, e.g., like in a Module -- I would refer you to the conversation around adding Sub-router functionality. It is something we've considered and we accept pull-requests.

Thanks!

@thepratt

This comment has been minimized.

Copy link
Author

commented Sep 21, 2015

@cacoco Thanks for the reply Chris!

The sub-router conversation was one I read, and would be a nice feature to see. The closest example of what I mean are Symfony2 bundles. They are self-contained sections of code that can be plugged into an application at the discretion of the user; this is very similar to finatra modules, minus the ability to hold controller/route addition within itself (registration for finatra is done outside of the module).

I'll watch #211 , and see if I can help w/ the solution. I was picturing a configureHttp inside a module definition, which would be registered when added to the modules Seq. This isn't quite a sub-router, but a different method to split up code.

I was a bit lost re the multi-server test, as I thought that was the preferred way, since multiple ServerMain objects causes sbt to ask you which to run, and I couldn't create a server that extends the one HttpServer with others.

@thepratt thepratt closed this Sep 21, 2015

@cacoco

This comment has been minimized.

Copy link
Member

commented Sep 21, 2015

If you have multiple main classes with sbt, I believe you can use the "runMain" command:

E.g.,

sbt "runMain com.thepratt.package1.Foo"

and then in another window

sbt "runMain com.thepratt.package2.Foo2"

See here: http://www.scala-sbt.org/0.13/docs/Command-Line-Reference.html

"runMain * Runs the specified main class for the project in the same virtual machine as sbt. The main class is passed the arguments provided. Please see Running Project Code for details on the use of System.exit and multithreading (including GUIs) in code run by this action. test:runMain runs the specified main class in the test code."

@thepratt

This comment has been minimized.

Copy link
Author

commented Sep 21, 2015

That will require me to define separate ports, and they'd be treated as self-contained entities, which could be better (I'd have to evaluate later).

Thanks Chris.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.