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

Dynamically configure maven dependencies for lightblue plugins #162

Closed
dcrissman opened this issue Jul 28, 2015 · 12 comments
Closed

Dynamically configure maven dependencies for lightblue plugins #162

dcrissman opened this issue Jul 28, 2015 · 12 comments
Assignees
Labels

Comments

@dcrissman
Copy link
Member

@dcrissman dcrissman commented Jul 28, 2015

From a maven dependency perspective, all possible plugins must be listed in lightblue-rest's pom file. You can already fine tune which plugins are actually used at runtime via the lightblue-metadata.json configuration, but all the possible plugins must still be listed in the pom.

It would be idea if you could truly configure what plugins you wanted to use. This would be beneficial for highly customized plugins that not anyone would want to use, or if you just want a lighter weight installation.

@dcrissman

This comment has been minimized.

Copy link
Member Author

@dcrissman dcrissman commented Jul 29, 2015

Found this article: http://stackoverflow.com/questions/402330/is-it-possible-to-add-to-classpath-dynamically-in-java

Maybe we create a 'magic' directory and any jars in it get loaded at runtime?

@jewzaam

This comment has been minimized.

Copy link
Member

@jewzaam jewzaam commented Jul 30, 2015

Probably could put the jar's for the hooks and controllers into a module, keeping the lightblue-rest pom clean. There are unit tests that depend on some of those things. Maybe they can be put into a separate module that has those hook and controller dependencies with a scope of test. The mongo controller is used all over the place, though, so we may want to deal with pulling that out separately. Could we start with just hooks to keep the scope smaller?

@alechenninger

This comment has been minimized.

Copy link
Contributor

@alechenninger alechenninger commented Nov 19, 2015

I do this commonly with combination of URLClassLoader and ServiceLoader: https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html

@dcrissman dcrissman changed the title Dynamicly configure maven dependencies for lightblue plugins Dynamically configure maven dependencies for lightblue plugins Nov 20, 2015
@dcrissman

This comment has been minimized.

Copy link
Member Author

@dcrissman dcrissman commented Nov 20, 2015

@alechenninger Does that get the jars onto the classpath?

I see once on the classpath, it is easily able to load services. Lightblue currently uses reflection to instantiate hooks and other plugins. I am not sure of the merits of one approach over the other.

I found an <a href=https://docs.oracle.com/javase/tutorial/ext/basics/spi.html#run-the-client">example, of ServiceLoader, where they are setting the java.ext.dirs flag on java. Which kind of goes back to the magic directory solution.

@alechenninger

This comment has been minimized.

Copy link
Contributor

@alechenninger alechenninger commented Nov 20, 2015

You can use URLClassLoader to create a classpath from a jar or directory. So, if you land the hooks somewhere and you add configuration to know where to look for hook jars, you can create these classloaders and load the services in them at runtime. Or, as naveen said, you could use some kind of "hooks" module that users could populate using puppet, and then you could use ServiceLoader to discover the hooks if you wanted.

@dcrissman

This comment has been minimized.

Copy link
Member Author

@dcrissman dcrissman commented Jan 19, 2016

I have added some PRs, but this all still needs testing and is not yet ready to be merged. I marked everything as in progress. That said, feel free to start reviewing.

@dcrissman

This comment has been minimized.

Copy link
Member Author

@dcrissman dcrissman commented Jan 28, 2016

I have made progress to the point that I can manually drop jar files into some directory and tell lightblue how to pull the in and add them to the class path. I am using lightblue-ldap as a test case.

My current thinking is that I will add the ability for lightblue-ldap to generate an rpm that can deploy the individual jars. This includes lightblue-ldap-core/crud/metadata/common and a ldap library (that does not have an rpm itself that I can find).

The question now, is where do we want the jar files to live? I would like to keep it non-specific to jboss if possible. My current thinking is a /var/lib/lightblue/ directory, but wanted to get some feedback before proceeding. Thoughts?

@alechenninger

This comment has been minimized.

Copy link
Contributor

@alechenninger alechenninger commented Jan 28, 2016

The question now, is where do we want the jar files to live?

Why not configurable in a properties file in the properties module? You can also have a default of course

@dcrissman

This comment has been minimized.

Copy link
Member Author

@dcrissman dcrissman commented Jan 28, 2016

To clarify, I will be using maven to generate the rpm similar to other lightblue deployable artefacts. So the install directory will be configurable, but the question is what to set the rpm.install.basedir too (or default if you prefer)?

As far as how to tell lightblue where the jar files are, will be configurable. See #162 for how that will work.

@dcrissman

This comment has been minimized.

Copy link
Member Author

@dcrissman dcrissman commented Jan 28, 2016

Going to drop the jars in /usr/share/java/lightblue/lightblue-ldap

@kahowell

This comment has been minimized.

Copy link

@kahowell kahowell commented Jan 28, 2016

FYI, we want to automate deployment of esbtools/lightblue-notification-hook. Waiting on this work to be complete before proceeding.

@dcrissman

This comment has been minimized.

Copy link
Member Author

@dcrissman dcrissman commented Jan 29, 2016

Keeping this issue alive because work still needs to be done.

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