Re: Loading in jars with dependencies at runtime into separate classloaders with independent classpaths
Thanks, I've had a look at Immutant. I don't really want to migrate my whole app to immutant's framework right now though (plus I'm just interested in how one might employ this pattern for things other than web apps too) so I've been looking through to see if I can work out how to do just the classloading/dependency resolution part. I can't seem to find anything though. Does that happen within the JBoss AS part of it rather than in clojure? Any input is much appreciated, thanks Adam On Monday, February 18, 2013 7:07:21 PM UTC, Toby Crawley wrote: Adam: You can do this exact thing in Immutant[1]. It can handle multiple applications at the same time, with each application getting an isolated ClassLoader. Each application can optionally have its dependencies resolved at deploy time via pomegranate, and can be (re)deployed independently of other applications within the same container. [1]:http://immutant.org Adam Clements writes: I'm working on a web api wrapper around a number of java/clojure libraries. One problem that I have run into is transitive dependency conflicts, especially when some of the projects are older than others. What I want to do is have each API endpoint's final handler function in its own classloader, with its own dependencies, ideally downloaded at runtime. That way none of them will interfere with one another and I can add new API endpoints without restarting the entire api server process. Is this possible? I have come across pomegranate for dependency resolution and classlojure for evaling in other classloaders, but I can't find any examples of doing both at once, and my experiments have so far been unsuccessful. Any hints would be much appreciated, Thanks, Adam -- -- Toby Crawley http://immutant.org | http://torquebox.org -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Loading in jars with dependencies at runtime into separate classloaders with independent classpaths
This is the problem that OSGI tries to address and that the long-delayed module system hopefully coming in JDK8 should handle (Project Jigsaw). I think currently OSGI might be your best bet if you truly need it, though there is quite a bit of work to get spun up on that. You may get lucky and be able to use :exclusions in your project.clj to make sure only the newest version of any dependency is used (assuming the new version doesn't break backwards compatibility). If you're brave, you could download an early-release of JDK8 and see how Project Jigsaw works for you. It is possible to spin your own solution using Classloaders, but probably a lot of work. On Mon, Feb 18, 2013 at 1:47 PM, Adam Clements adam.cleme...@gmail.comwrote: I'm working on a web api wrapper around a number of java/clojure libraries. One problem that I have run into is transitive dependency conflicts, especially when some of the projects are older than others. What I want to do is have each API endpoint's final handler function in its own classloader, with its own dependencies, ideally downloaded at runtime. That way none of them will interfere with one another and I can add new API endpoints without restarting the entire api server process. Is this possible? I have come across pomegranate for dependency resolution and classlojure for evaling in other classloaders, but I can't find any examples of doing both at once, and my experiments have so far been unsuccessful. Any hints would be much appreciated, Thanks, Adam -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Loading in jars with dependencies at runtime into separate classloaders with independent classpaths
Adam Clements writes: I don't really want to migrate my whole app to immutant's framework right now though (plus I'm just interested in how one might employ this pattern for things other than web apps too) so I've been looking through to see if I can work out how to do just the classloading/dependency resolution part. I can't seem to find anything though. Does that happen within the JBoss AS part of it rather than in clojure? The classloader isolation is provided by a combination of the AS itself (specifically its JBoss Modules[1] component) and java shims within Immutant. The dependency resolution is handled my a combination of java and clojure code, which uses pomegranate via leiningen-core in a module that is isolated from the application to prevent the leiningen-core dependencies from bleeding over. If you are looking for a clojure example of using JBoss Modules for isolation, see hiredman's polycosm[2] project. If you want to discuss isolation and runtime dependency in more detail, find me in #immutant on freenode. I'm happy to tell you what I know. And even though it's often used and discussed for web applications, Immutant can be used as a general container for many non-web clojure applications. [1]: https://docs.jboss.org/author/display/MODULES/Introduction [2]: https://github.com/hiredman/polycosm -- Toby Crawley http://immutant.org | http://torquebox.org -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Loading in jars with dependencies at runtime into separate classloaders with independent classpaths
Adam Clements writes: I'm working on a web api wrapper around a number of java/clojure libraries. One problem that I have run into is transitive dependency conflicts, especially when some of the projects are older than others. If you are dealing solely with conflicts in Clojure code and not Java classes, you don't need separate classloaders; you can munge the ns forms prior to load instead: https://github.com/technomancy/metaverse This is still very experimental, but may be a promising approach with some work. -Phil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Loading in jars with dependencies at runtime into separate classloaders with independent classpaths
I'm working on a web api wrapper around a number of java/clojure libraries. One problem that I have run into is transitive dependency conflicts, especially when some of the projects are older than others. What I want to do is have each API endpoint's final handler function in its own classloader, with its own dependencies, ideally downloaded at runtime. That way none of them will interfere with one another and I can add new API endpoints without restarting the entire api server process. Is this possible? I have come across pomegranate for dependency resolution and classlojure for evaling in other classloaders, but I can't find any examples of doing both at once, and my experiments have so far been unsuccessful. Any hints would be much appreciated, Thanks, Adam -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Loading in jars with dependencies at runtime into separate classloaders with independent classpaths
Adam: You can do this exact thing in Immutant[1]. It can handle multiple applications at the same time, with each application getting an isolated ClassLoader. Each application can optionally have its dependencies resolved at deploy time via pomegranate, and can be (re)deployed independently of other applications within the same container. [1]:http://immutant.org Adam Clements writes: I'm working on a web api wrapper around a number of java/clojure libraries. One problem that I have run into is transitive dependency conflicts, especially when some of the projects are older than others. What I want to do is have each API endpoint's final handler function in its own classloader, with its own dependencies, ideally downloaded at runtime. That way none of them will interfere with one another and I can add new API endpoints without restarting the entire api server process. Is this possible? I have come across pomegranate for dependency resolution and classlojure for evaling in other classloaders, but I can't find any examples of doing both at once, and my experiments have so far been unsuccessful. Any hints would be much appreciated, Thanks, Adam -- -- Toby Crawley http://immutant.org | http://torquebox.org -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
