search

stainlessai / micronaut-jupyter

A Micronaut configuration that integrates your app with an existing Jupyter installation.
https://stainlessai.github.io/micronaut-jupyter
Apache License 2.0
9 stars 5 forks source link

MJ-3 ⁃ Access Spring beans in Jupyter script #19

Closed stainlessbot closed 4 years ago

stainlessbot commented 4 years ago

In Grails and Micronaut, services are made available via beans. Make these beans accessible from within a Jupyter script. The current grails-ingestor plugin does this by making the application context available via a binding and then providing a "service()" method on the abstract class that gets the bean from the application context.

In order to bind the application context, some additional BeakerX classes may need to be subclassed (see https://github.com/twosigma/beakerx/blob/master/kernel/groovy/src/main/java/com/twosigma/beakerx/groovy/evaluator/GroovyCodeRunner.java).

Also, a shortcut "service" method should be made available (MJ-4).

┆Issue Type: Story ┆Priority: High ┆Status: Resolved ┆Fix Versions: v0.2.0 ┆Issue Number: MJ-3 ┆Epic: Kernel

stainlessbot commented 4 years ago

➤ Joshua Carter commented:

Micronaut doesn't offer any type of Holders class like Grails does. So the only two options I see are to either set the application context on the binding, or inherit the script from a base class that allows the application context to be set on the instance of the script. Since we have to do that anyway for MJ-4, it probably makes more sense to go this route.

stainlessbot commented 4 years ago

➤ Joshua Carter commented:

Provide a service() method that will return bean instances as in old Hapnin scripts. For now, this method will require the actual class to specify the bean type; however, the ability to specify a string as some sort of identifier can be added as part of a different ticket.

stainlessbot commented 4 years ago

➤ Joshua Carter commented:

The GroovyEvaluator uses the GroovyClassLoader factory to set the compiler config on the class loader. This configuration is almost certainly not something that should be left out. Instead of completely replacing the beaker class loader in GroovyCodeRunner, it will probably be better to return a customized class loader from the evaluator.