Hi No there is not so many on the guice wagon.
I dont think you need the guicy fruit anymore, we are on guice 3.0. I recall the fruit was to make it workable in the earlier days of guice. But we love contributions. So you and others are sure welcome to improve camel-guice in any way. Whether its code, docs, examples or whatnot. http://camel.apache.org/contributing.html On Fri, Mar 27, 2015 at 3:57 PM, Jakub Kotowski <ja...@sindicetech.com> wrote: > Thanks for the replies. > > After studying the code, I solved it independently like Willem Jiang > suggests: > > public class MyCamelContext extends GuiceCamelContext { > @Inject > public MyCamelContext(Injector injector) { > super(injector); > } > > @PostConstruct > public void start() { > setTracing(true); > > // etc. > > super.start(); > } > } > > > But then I immediately got stuck with a new problem. I wanted to configure > my application from command line arguments and that seems impossible to do > cleanly with the Camel Guice Main. > > In the end, I found an ugly hack which is however quite localized: > > public class MyMain extends Main { > > // this is the ugly hack - a static variable that can be accessed > from a Guice Module > > // Guice doesn't run until main.run(args) is called so it's safe > > public static MainArgs mainArgs; > > > public MyMain(String args[]) throws InterruptedException { > mainArgs = new MainArgs(); > mainArgs.setArgs(args); > > addOption(new ParameterOption("c", "conf", "Path to the > application.conf configuration file.", "filePath") { > @Override > protected void doProcess(String arg, String parameter, > LinkedList<String> remainingArgs) { > mainArgs.setConfFile(parameter); > mainArgs.loadAndValidateConf(); > } > }); > } > > public static void main(String args[]) throws Exception { > Main main = new MyMain(args); > > main.enableHangupSupport(); > main.run(args); > } > } > > > Then I have MainArgsModule which provides MainArgs via normal dependency > injections - this way I can restrict the ugly static access to this one > class while the rest of the app can use dependency injection as usual. > > public class MainArgsModule extends AbstractModule { > @Override > protected void configure() { > } > > @Provides > public MainArgs createMainArgs() { > return MainFlowGuice.mainArgs; > } > } > > jndi.properties: > > java.naming.factory.initial = > org.apache.camel.guice.jndi.GuiceInitialContextFactory > org.guiceyfruit.modules = com.myapp.ApplicationModule com.myapp.MainArgsModule > > > I guess that really not many people use Guice with Camel when there are > such basic issues using it? I am wondering how much more friction there > will be and whether it wouldn't make more sense to simply use Spring as > most do (even though Spring is not my first choice otherwise). > > Later I could of course write my own Main for Guice, etc. but I was > hoping to get started rather quickly. > > > Jakub > > > On Thu, Mar 26, 2015 at 9:54 AM, dermoritz <tantea...@hotmail.com> wrote: > >> i just created an ticket with a suggestion: >> https://issues.apache.org/jira/browse/CAMEL-8555 >> >> >> >> -- >> View this message in context: >> http://camel.465427.n5.nabble.com/Setting-up-CamelContext-with-Guice-tp5764709p5764818.html >> Sent from the Camel - Users mailing list archive at Nabble.com. >> -- Claus Ibsen ----------------- Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
