If everything depends on CLI input, you could wrap it in a 'settings' object and inject that object where needed, rather than use assisted injection everywhere.
--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to a topic in the Google Groups "google-guice" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-guice/c9fipvWw1j8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-guice...@googlegroups.com.
It does work, I've done it multiple times this way. It's very easy of you use args4j, you then already have a little pojo which wraps your command line arguments.
What you then need to do is: bind your settings to that one instance and let your Z depend on it. Everything else just depends on their direct dependency.
I have an InfrastructureService, which require a KnowledgeBaseService which in turn require anConFigDataObject. My configDataObject contains information coming from the inputs of the program.The configDataObject store these information after doing some validation and processing on those inputs. For instance a string representing file path can be provided to it, and it will validate that it is a file that exist, and provide a getter method that return that File to its consumer (i.e instead of the fileName). Other things might be URLNname to real URL Object, and so on.
The important point here is this following graph: InfrastructureService -> KnowledgeBaseService ->ConFigDataObject -> InputData
Therefore the InfrastructureService can only work with a knowledgeBaseService that is started with the right inputFile, URL, workingfolder and etc.... which is provided to it with a configDataObject, that receive them from the input of the program and store a processed version of them.
Therefore as of now what i do is to have a assistedFactory to create the knowledgeBaseService. It takes as parameter the ConfigDataObject. The configDataObject is created with a factoryMethod (Scala Companion Object). Finally, the an assistedFactory is also create for the InfrastructureServicewhich takes as parameter for its creation method a KnowledgeBaseService.
So what exactly are you recommending here ? Would suggest to:
val data = new ConfigData(.....)
Class module extends AbstractModule {
bind(Configdata).toInstance(data)
.....
}
I have to try.... but let me know if i got u right please
Here is what i did to finally solve the issue in a more elegant way than using an unnecessary chain of assisted injected due to the parameters of the application.
that is If as in my case your data comes from the command Line then the right appraoch i believe is to bind the type of the input data structure to instance input structure obtained from the command line:
object MyApp extends App {
val config = ConfigData(args(0))
val injector = Guice.createInjector(module(config))
val service = injector.getInstance(classOf[InfrastructureService])
println("The service name is:" + service.kbService.config.configName)
}
case class module(config: ConfigData) extends AbstractModule {
def configure(): Unit = {
bind(classOf[ConfigData]).toInstance(config)
}
}
case class ConfigData(val configName: String)
class KbService @Inject() (val config: ConfigData)
class InfrastructureService @Inject() (val kbService: KbService)
I believe the Key here is to remind yourself that the module can be parameterize with any input data deem necessary
Is it what you guys had in mind ?
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice+unsubscribe@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to a topic in the Google Groups "google-guice" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-guice/c9fipvWw1j8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-guice+unsubscribe@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to a topic in the Google Groups "google-guice" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-guice/c9fipvWw1j8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.