2

According to the Spring boot documentation, it's possible to define additional command when using a remote shell based on Crash.

Default locations for these commands are classpath*:/commands/,classpath*:/crash/commands/

A property can be used to override the default locations but in the provided example, the custom command is located in resources.

In my opinion, custom commands (at least java commands) shouldn't be located in resources but in src/main/java.

It works fine when defining a custom path in resources but how can I define a custom path in src/main/java? Didn't find a way to do it for now!

xenoterracide
  • 16,274
  • 24
  • 118
  • 243
François Rosière
  • 259
  • 1
  • 12
  • I would like to know this as well because I would like to make commands that have access to the spring context, and of course other classes on my classpath. – xenoterracide Oct 12 '15 at 02:27
  • @xenoterracide The [documentation](http://www.crashub.org/1.3/reference.html#command_context) is not that explicit for the time being, however this statement was a good starting point for me `def bean = context.attributes.beans["TheBean"];`. What I did in Java, was to extend `org.crsh.command.BaseCommand` and created my method `protected T getSpringBean(Class beanClass)` which simply does `return ((BeanFactory) this.context.getAttributes().get("spring.beanfactory")).getBean(beanClass);` – Morfic Oct 12 '15 at 08:35

2 Answers2

1

If they're under src/main/java, they'll be compiled automatically which is not what you need. My solution was to simulate that directory as a resources folder, which in short translates to:

  1. configure the compiler plugin to ignore that particular folder
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.3</version>
        <configuration>
            <source>${java.version}</source>
            <target>${java.version}</target>
            <excludes>
                <exclude>crash/commands/*</exclude>
            </excludes>
        </configuration>
    </plugin>
  1. copy the files just like any regular resources in the target directory
    <resource>
        <directory>src/main/java/crash/commands</directory>
        <targetPath>crash/commands</targetPath>
        <filtering>false</filtering>
    </resource>

Minor update & disclaimer:

As you may already know, there are a couple of closures which are executed on login/logout. At least with v1.3.1, which is what I'm blindly inheriting from spring-boot, it will pick the first login.groovy it finds in the classpath. My project's artifact is packaged in an RPM along with all the other dependencies. Since its name begins with r, it comes after crash.shell-1.3.1.jar which is where the defaults reside, so I had to do the following small hack to make it pick up my own scripts instead of the default ones:

<!-- hack to make CRaSH pick up login.groovy from our jar instead of the default one -->
<finalName>0_${project.artifactId}-${project.version}</finalName>
Morfic
  • 15,178
  • 3
  • 51
  • 61
  • "they'll be compiled automatically which is not what you need." why is this a problem? and you mention groovy when the op wants java. – xenoterracide Oct 12 '15 at 02:11
  • @xenoterracide 1) Hmm, If I recal corrrectly, CRaSH looks for and compiles the command sources itself. If they're already compiled it won't find them 2) Commands can be implemented in either java or groovy, but afaik those executed on login/logout are just groovy closures, and those 2 are the only references to _groovy_. Am I missing something else? – Morfic Oct 12 '15 at 10:56
  • probably not it's just really not obvious why CRaSH thinks it *has* to compile things itself. I mean I get doing groovy at runtime, but why does it have to be able to compile Java, probably a better question for the CRaSH devs though. – xenoterracide Oct 12 '15 at 23:06
  • @xenoterracide One of the reasons is to facilitate development as you can write them during runtime and it will immediately pick up your changes. Another one could be that it does some kind of instrumentation but it's only a supposition and I didn't, yet, take a look at the sources. **P.S.** You may have already noticed, but if you didn't, I also replied to the comment you added to the question regarding _spring_ access. Cheers – Morfic Oct 13 '15 at 11:24
  • yeah I get they might be doing stuff, but all that stuff can be done in other ways than compiling the sources themselves. Just kind of aggravating to have to do this stuff. I'm not saying they shouldn't do this, they should just allow us to not do this, I am debating on filing a bug, but I don't actually have a direct use case, I'm just demo-ing the tech as part of a Spring Boot presentation. – xenoterracide Oct 13 '15 at 13:36
-1

You can try to put your command at src/main/resources/commands/

Balicanta
  • 109
  • 6