I'm trying to attach the Java 9 or Java 11 source for some projects released as MRJARs, namely jersey-container-jetty-http-3.0.2 and junit-platform-commons-1.4.0.
Looking at the jersey-container-jetty-http-3.0.2-sources.jar file in my ~/.m2/repository there is no META-INF/versions directory and the .java files in standard package locations are for Java 8 (pre module system). This is also the case if I unpack https://repo1.maven.org/maven2/org/glassfish/jersey/containers/jersey-container-jetty-http/3.0.2/jersey-container-jetty-http-3.0.2-sources.jar
This is a big bummer for my debugger :(
I was able to download the full source code from https://github.com/eclipse-ee4j/jersey/releases/tag/3.0.2, and it contains the following directories, with source:
containers/jetty-http/src/main/java11
containers/jetty-http/src/main/java8
I thought maybe this was just a Jersey problem, but looking at junit-platform-commons-1.4.0 I see a similar issue. Neither my ~/.m2/repository nor https://repo1.maven.org/maven2/org/junit/platform/junit-platform-commons/1.4.0/junit-platform-commons-1.4.0-sources.jar contain code for any java 9+ version but the release JAR contains /META-INF/versions/9/org/junit/platform/commons/util/ModuleUtils.class.
So my question: Is including source for multiple Java versions supported by Maven? If so, where are the Java 9+ source files be located?
The maven-source-plugin:jar goal which:
[...] bundles all the sources into a jar archive.
doesn't mention MRJAR explicitely but it has the parameter:
Name
Description
<includes>
List of files to include. Specified as fileset patterns which are relative to the input directory whose contents is being packaged into the JAR.
Currently, I am passing the environment specfic configs in a properties file outside the jar using -Dspring.config.location=/apps/conf/application-dev.properties. I also have properties file included in the jar named application.properties which has configs that don't change often. There's one config called nameFile:
nameFile=classpath:config/nameList.txt
And the actual nameList.txt is included in the jar under spring-app/src/main/resources/config/nameList.txt but I want to move the nameList.txt outside the jar.
What I've tried:
Changing it to nameFile =${auth.nameList} and added this to /apps/conf/application-dev.properties like:
auth.nameList=classpath:/apps/conf/nameList.txt
And I moved the nameList.txt file from the jar to /apps/conf/ location but the Spring application fails because it cannot find the txt file. How do I fix this? I want to move the nameList.txt to outside the jar.
Removed classpath:
auth.nameList=/apps/conf/nameList.txt
No luck!
When you provide a path, classpath will "tell" the JVM that the location is within the jar/war file. If you have the resource you need in an external location, you will need file instead.
auth.nameList=file:/apps/conf/nameList.txt
I need to load a property file from src/main/resources/config folder. The loading part is written in a common dependency project where we dont have any control. We are just passing the file name expressed through a dependency. The code snippet in the dependent jar is like below, the standard resource loading.
InputStream inputStream = this.getClass().getClassLoader().getResourceAsStream(propertyFileName);
Spring will always look for recources under recources folder directly, in this case its unable to load the file as its in the custom folder and its not under classpath.
How do we explicitly set the custom folder as additional classpath folder?
With maven we could do something like below which works fine. Is there any OOTB way to achieve this with annotation in spring boot?
`<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>src/main/resources/config</directory>
</resource>
</resources>`
Updated
`// This works if config.properties is directly under resource folder
// What if config.properties is under resources/config folder.
// Dont say to pass argument as /config/config.properties, there are some other limitations.
// So in that case with the same approach, config should come under classpath, so that the below
// method will work always when the property name is passed.
// As mentioned earlier, we can use maven resource settings to achieve this.
// The question here is, is there any way to explicitely advise spring to load property from this folder.
// I have seen something like loader.path config, not sure that helps!
InputStream stream = SpringBootStarter.class.getResourceAsStream("/config.properties");`
Before answering, when you say: Spring will always look for recources under recources folder directly, in this case its unable to load the file as its in the custom folder and its not under classpath., this is not correct.
Spring can look anywhere on your system. Here is how you can load different properties file with Spring and Spring boot:
#PropertySource("classpath:config/common.properties") => Will look under the class path for a file located under the config folder, at the root of your classpath.
#PropertySource("file:/config/common.properties") => Will look for the file common.properties at the root of your filesystem, here under /config/common.properties.
Now, there is the question of "what is the classpath", it seems like it is worth more explanation.
The classpath is for the JVM what the filesystem is for your OS. When you execute some java code (.jar file for instance), the JVM stores all the files you specify. You can specify files when executing java -classpath /a/shared/folder,/a/dependency/app.jar,myApp.jar MainClass. (See this for some others ways: https://javarevisited.blogspot.com/2012/10/5-ways-to-add-multiple-jar-to-classpath-java.html).
Quite often, what happens for developers (before we use Spring) was this:
We develop our application, and use maven for managing the dependencies
We execute our app with the IDE, everything works just as fine, life is wonderful
We are ready to go live (in production). We generate the famous myApp.jar and try executing the application java -jar myApp.jar and... Nothing works. You have issues with java (I assume you setup the main-class in the Manifest...) and you get something like Caused by: java.lang.ClassNotFoundException: my.dependency.OtherClass...
Finally, you realize life is hard and you are not ready to go live right now. You need to have something you can execute easily.
One possible solution to this, to avoid having classpath issues is to put everything in your JAR (called in spring-boot the FAT jar) and you use java -jar myApp.jar and it is working fine.
By default, when you generate a maven project, automatically you have some folders included like:
src/main/java => your java files and packages
src/main/resources => your config files (like .properties)
src/test/java => Your java test files
src/test/resources => the resources handy for your tests
When you generate your jar (more or less every configuration you added to your maven project, but let's say it is okay), what happens is the compiler takes all the folders and files under src/main/java and src/main/resources and put them at the root of your jar. (Don't hesitate to have a look inside your jar files. This is just a Zip, you can open it, browse it, and see for yourself).
With that said, when you say How do we explicitly set the custom folder as additional classpath folder?, and you talk about a custom folder located under src/main/resources, then when you generate your Jar, the custom folder will be in jar, and therefor, in your classpath.
If you still have troubles, this actions will help you:
Unzip your jar files and check what is inside. If you don't see any config/ folder in it, maybe your Jar generation is wrong
Try using #PropertySource(...) to load properties file, in your classpath and in your filesystem, to see how it works and what you achieve
Have also a look to this:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
Don't hesitate to migrate more and more of your old code to Spring-boot, will be a lot easier for you.
We use eclipselink in our applications therefore we configured JBoss to use eclipselink as persistence provider. We configured this by putting the eclipselink.jar into the following path:
JBOSS_HOME/modules/system/layers/base/org/eclipse/persistence/main
In addition we have changed the module.xml accordingly. After that we could use it and it worked fine.
Now we want to configure the jboss with a command line script to avoid manual work. In addition the jboss should be patched to the current patch level (jboss eap 7.0.7).
After applying the patch the eclipse persistence module is in the following path:
JBOSS_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-7.0.7.CP/org/eclipse/persistence/main
With a later patch the path could be different therefore we don't want to copy files in absolute paths.
Is it somehow possible to use the jboss-cli to configure this module (add jar and change module.xml)?
You can use
module add --name=MODULE_NAME --resources=PATH_TO_RESOURCE --dependencies=DEPENDENCIES --module-xml=YOUR_MODULE.XML
--module-xml - (used with add, optional) filesystem path to the module.xml
file which should be used for the added module. The file will
be copied to the created module's directory. If this argument
is not specified, module.xml file will be generated in the
new created module's directory.
MODULE_NAME should be org/eclipse/persistence/main in your case
On my Oracle weblogic 12 installation I have deployed an .ear (built with maven). All is OK except when I go to wls-cat and check Classloader Tree I get entries such as:
D:\Oracle\Middleware\Oracle_Home\user_projects\domains\liferayportal\servers\AdminServer\tmp\_WL_user\mywebapp\nsio4q\APP-INF\lib\lib\antlr-2.7.6.jar
and
D:\Oracle\Middleware\Oracle_Home\user_projects\domains\liferayportal\servers\AdminServer\tmp\_WL_user\mywebapp\5ohvco\war\WEB-INF\lib\..\..\lib\
I have no \lib\lib folder and neither do \lib...\...\lib
What can be the cause? What should I check in my POMs? Thank you.
This is not related to your pom.xml
WLS expands the war file, but copy the files in different places, therefor It doesn't recreate a directory structure (ie: OC4J does it).
Therefore, WLS-CAT is telling where (psychically) is retrieving a particular class (from antlr jar file in your case).