[SOLVED] Start script simetheral log4j netbeans/sdk

General Discussion
1

First of two questions.

When using the application plugin, sdk/netbeans and build task you generate a distribution with a startup script for unix/windows.

This works great except for it throws a error when using a log4j.xml config file.

ERROR StatusLogger No Log4j 2 configuration file found.

So the solution I thought was to add the jvm argument to the build file.

application {
    applicationDefaultJvmArgs = ['Dlog4j.configurationFile=server-log4j2.xml']
    mainClassName='com.xxx.server.GameServer'
}

However, this causes the exception,

Error: Could not find or load main class Dlog4j.configurationFile=server-log4j2.xml

The startup script shows the correct setting,

@rem Add default JVM options here. You can also use JAVA_OPTS and XXX_SERVER_OPTS to pass JVM options to this script.
set DEFAULT_JVM_OPTS="Dlog4j.configurationFile=server-log4j2.xml"

So when,

set DEFAULT_JVM_OPTS=

it cant find the xml file, even though its in the default package of the distribution jar and when its set it cant find the main class.

Any ideas on what I am doing wrong?

2

Doesnā€™t it have to be in the resources directory? Every configuration I have goes in there. To be clear itā€™s the /src/main/resources/ dir.

3

Yes, thats where it is but what I read, and what is happening is it gets moved to the distribution jar under the default package.

I am looking for the note on it now. Will post link.

4

OMFG!

Frigging jvm argument was missing the minus sign (-)

    applicationDefaultJvmArgs = ['-Dlog4j.configurationFile=server-log4j2.xml']

Lost many many hours to this. Stupid ass syntax error with a generic error description.

I couldnā€™t find where I read the info on the log4j2.xml being under the default package in the distribution jar but I know I read it and it was a one sentence blurb among the hundreds I have read. Searched bing and google and nothing now. I know I didnā€™t imagine it.

I will post the second question shortly.

1 Like
5

Part of what I am doing is learning how Paul uses gradle with simethereal but I am using gradle 5.4.1 so things can get tough to figure out sometimes.

When using the simethereal build script to build the startup bat file, we have this CreateStartScripts,

// Create a custom server start script in the distribution
task serverStartScript(type: CreateStartScripts) {
    mainClassName = "com.xxx.server.GameServer"
    applicationName = "server"
    outputDir = new File(project.buildDir, 'scripts')
    classpath = jar.outputs.files + project.configurations.runtime
    defaultJvmOpts = ['-Dlog4j.configurationFile=server-log4j2.xml']
}

There is a small problem when this runs. I understand whats going on except for how to fix this line,

classpath = jar.outputs.files + project.configurations.runtime

This will only add the runtime jars of dependencies when using gradle 5.4.1.

For this question those are,

runtime project(':assets')
runtime 'org.apache.logging.log4j:log4j-slf4j-impl:2.11.2'

I am trying to understand how to get all the dependencies onto the classpath including local jars and how this line actually works.

The sdk/netbeans default script builds perfectly now so I am trying to get the simethereal task to do the same build but it is missing adding all the implementation configuration and local jars on the classpath.

I would like to read about it in the gradle docs if someone can point to the proper way to implement a solution.

6

I wonder if itā€™s lazy-resolving the transitive dependencies. Usually there would be some way to get the resolved list of dependencies. I donā€™t know if any of that will help your google searching.

You might be able to look into how the regular application plugin sets up its own classpathā€¦ but that might take a little digging.

The good thing about Gradle is that it evolves very quickly and almost always for the betterā€¦ the bad thing about Gradle is that it evolves very quickly and sometimes ā€œbetterā€ will break an older build if you arenā€™t pegging the version with gradlew.

7

I have everything working (including gradlew) except this classpath part of the CreateStartScripts and I cant let go of stuff like this until I kill it.

I dont fully understand project.configurations.runtime since I cant find a reference to it in the docs yet.

Looks like there are no shortcuts on this one, gonna have to do it the old fashion way and learn it down to the last gory detail.

8

Since I donā€™t know where your understand falls offā€¦ Iā€™ll explain what I know.

ā€˜projectā€™ is the instance of your project. The thing instantiated for your build file. (Hopefully this one was obvious.)

ā€˜configurationsā€™ are the various project configurations for compile, runtime, etcā€¦ The things you attach dependencies to, basically. Everything in your ā€œdependencyā€ block will map back to one of these. In newer gradle, the set of available configurations changed a LOT.

ā€˜runtimeā€™ is then the ā€˜runtimeā€™ Configuration. Itā€™s the set of runtime dependenciesā€¦ but should have methods/properties for getting just the local dependencies, resolving the transitive dependencies, etcā€¦ A long time ago, there were things like runtime.resolve or runtime.resolveTree or something and then they made it easier to work with as the configuration would provide the resolved set.

ā€¦that must have changed again.

9

Got it.

https://docs.gradle.org/current/userguide/upgrading_version_4.html#rel5.0:java_library_distribution_plugin

Found a blurb about runtime.

Additionally, the default distribution created by the plugin will contain all artifacts of the runtimeClasspath configuration instead of the deprecated runtime configuration.

Changing to,

    classpath = jar.outputs.files + project.configurations.runtimeClasspath

fixes it.

3 Likes