I have an EAR file that contains two different jars that share some classes with an identical package+class name. This results in importance of classloading inside the EAR file itself.
How can I tell Weblogic to load one jar from APP-INF/lib before loading a different one in the same APP-INF/lib? I need to define a specific order to that if there is a conflict, it will take from JAR a and not JAR b.
I'm using Webogic 11g (10.3).
Thanks.
The top-level element in weblogic-application.xml has an optional classloader-structure element that you probably want to look into. For instance you can do something like:
<classloader-structure>
<module-ref>
<module-uri>ejb1.jar</module-uri>
</module-ref>
<module-ref>
<module-uri>web3.war</module-uri>
</module-ref>
<classloader-structure>
<module-ref>
<module-uri>web1.war</module-uri>
</module-ref>
</classloader-structure>
</classloader-structure>
Read more about declaring custom class loading at these Oracle docs. You may also find the Classloader Analysis Tool (CAT) at the same link of interest.
If you're getting ClassNotFound exceptions, try checking out the MANIFEST.MF for each of your modules to see if the "Class-Path" attribute is correctly populated with the locations of your jars in your APP-INF/lib - I've just spent a week or more tearing my hair out trying to find a solution to a similar problem, and this is what fixed it.
Related
The Intellij Idea show the External Libraries with group, version and jar, it seems too long, how to simply show aopalliance-1.0.jar on the top like in Eclipse??
That's currently not possible in IDEA.
Bear in mind that some libraries can contain multiple jars (for example expand the "<1.8>" library).
Also the dependency is defined by the group/artifact/version strings, so it makes sense to show them on the top level node.
However I agree that having exactly one node under the top level node for almost every library in the project is unnecessary and not good for usability.
So maybe the two nodes could be collapsed into a single node that shows both the jar name and the group/artifact/version string - with one of it probably grayed out a little.
I suggest you create a feature request at JetBrains issue tracker: https://youtrack.jetbrains.com/issues/IDEA
This should be an easy one, but it's driving me mad. I'm new to implementing plugins, and one that I'm looking at has the following dependency:
<depends>com.intellij.modules.lang</depends>
I cloned the intellij-community project and was expecting to see this defined as an extensionPoint in one of the many plugin.xml files in the project, but either I can't search correctly or it is somewhere else.
Anybody knows where I can find this definition?
Thanks,
a
I'm still no expert in plugin development, but I think I figured out parts of my problem.
First, I was wrong about com.intellij.modules.lang having to be defined as an extension point. Name of extensions need to have corresponding extension points, not dependencies.
Then com.intellij.modules.lang is defined in a
<module>
tag in a few xml files in the intellij source code, which is part of the SDK used by this project. One such file is platform/platform-resources/src/META-INF/PlatformLangPlugin.xml. Now I need to familiarize myself with the concept of modules, but the original question is not moot.
Thanks to anyone who spent a few seconds thinking about this problem.
We're trying to migrate from current Ant build to Maven. In the current project, we've different properites files for each of the env say
qa.properties, prod.properties & dev.properties.
The property values present in these files, are used to replace wherever these properties are being referred through config files (present in src\main\resources\config ). The current Ant build process replaces all these properties which are being referred in config files with their corresponding value for the current build env.
I'm somewhat aware of the Profiles concept in maven. However, I'm not able to figure how to achieve this using maven.
Any help would be appreicated.
Thanks,
Prabhjot
There are several ways to implement this but they are all variations around the same features: combine profiles with filtering. A Maven2 multi-environment filter setup shows one way to implement such a setup (a little variation would be to move the filter declaration inside each profile).
See also
9.3. Resource Filtering
I wonder what is the Maven way in my situation.
My application has a bunch of configuration files, let's call them profiles. Each profile configuration file is a *.properties file, that contains keys/values and some comments on these keys/values semantics. The idea is to generate these *.properties to have unified comments in all of them.
My plan is to create a template.properties file that contains something like
#Comments for key1/value1
key1=${key1.value}
#Comments for key2/value2
key2=${key2.value}
and a bunch of files like
#profile_data_1.properties
key1.value=profile_1_key_1_value
key2.value=profile_1_key_2_value
#profile_data_2.properties
key1.value=profile_2_key_1_value
key2.value=profile_2_key_2_value
Then bind to generate-resources phase to create a copy of template.properties per profile_data_, and filter that copy with profile_data_.properties as a filter.
The easiest way is probably to create an ant build file and use antrun plugin. But that is not a Maven way, is it?
Other option is to create a Maven plugin for that tiny task. Somehow, I don't like that idea (plugin deployment is not what I want very much).
Maven does offer filtering of resources that you can combine with Maven profiles (see for example this post) but I'm not sure this will help here. If I understand your needs correctly, you need to loop on a set of input files and to change the name of the output file. And while the first part would be maybe possible using several <execution>, I don't think the second part is doable with the resources plugin.
So if you want to do this in one build, the easiest way would be indeed to use the Maven AntRun plugin and to implement the loop and the processing logic with Ant tasks.
And unless you need to reuse this at several places, I wouldn't encapsulate this logic in a Maven plugin, this would give you much benefits if this is done in a single project, in a unique location.
You can extend the way maven does it's filtering, as maven retrieves it's filtering strategy from the plexus container via dependency injection. So you would have to register a new default strategy. This is heavy stuff and badly documented, but I think it can be done.
Use these URLs as starting point:
http://maven.apache.org/shared/maven-filtering/usage.html
and
http://maven.apache.org/plugins/maven-resources-plugin/
Sean
I've a repository containing snapshot artifacts with timestamps.
I want to create an assembly, that contains the dependencies. This works fine. But the artifact names contains the timestamp. So i wonder how to remove the timestamp from filename for the assembly only.
I've used this dependencySet:
<outputFileNameMapping>${artifact.artifactId}-${artifact.version}.${artifact.extension}</outputFileNameMapping>
But version seams to contain already the timestamp. So is there any chance to get a 1.1.1-SNAPSHOT instead of 1.1.1-20100323.071348-182?
I'm using version 2.2-beta-4 of maven-assembly-plugin.
Could you try the following for the outputFileNameMapping:
${artifactId}-${baseVersion}.${extension}
According to issues like MASSEMBLY-67, MASSEMBLY-91:
Using ${baseVersion} for cases where you want to preserve the -SNAPSHOT naming, the plugin retains the ability to use ${version} for the timestamp-buildnumber naming, which is useful for describing the exact library version included in the assembly.
Update: After feedback from the OP, the exact syntax is (wasn't totally sure of this):
${artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}
I faced a similar issue when trying to build a bundle with the assembly plugin which contained a folder with the version number (I'm packaging WSDLs and XSDs).
The workaround I found is quite simple, I put the actual version number in a property (e.g. 1.0), which makes it available in the bundle.xml file for the assembly plugin, and set the pom version's to:
<version>${service.version}-SNAPSHOT</version>
This way the content of my package isn't influenced by the SNAPSHOT marker, in particular it isn't modified when doing the release.