We Keep Coding

Maven `<module>` accepting many different relative paths

From maven doc :
modules/module* - List (Many) - The modules (sometimes called
subprojects) to build as a part of this project. Each module listed is
a relative path to the directory containing the module. To be
consistent with the way default urls are calculated from parent, it is
recommended to have module names match artifact ids.
But my little experimentation shows that it accepts a lot more than mentioned. It accepts ./artifactId also and artifactId also. It even accepts ./artifactId/pom.xml . Why ?
Has the doc missed the point of mentioning that we can provide relative path till pom.xml of that module too ?

Need in understanding classpath in resource location and variable value set

Although I have been working in java for a while, there are many small things I have been ignoring, which at times have become bottleneck in productivity. I have difficulty in understanding this:
This is one of the bean.xml which gets placed in the final .war file (in a web application, built with spring framework).
<context:property-placeholder
location="classpath:/${deploy.env}/com.example.config/db.properties"
ignore-resource-not-found="false" />
I have following doubts:
1) At the time of building the code, i did like this for passing value of deploy.env
mvn clean install -Ddeploy.env=local
I ran the mvn in debug mode and could see this set to local. Now, the thing is, in the .war that gets generated, it is still ${deploy.env} (see above snippet). Doesn't this get replaced in the final .war? If not, then how do we pass the value which we intend to set?
2) what does "classpath:/${deploy.env}/com.example.config/db.properties" mean? Who sets the value of classpath? Are classpath capable of providing the location of resource files as well?
Assuming deploy.set --> local, so would this get translated to:
classpath:"/local/com.example.config/db.properties"
So does this mean db.properties would be present at: /local/com.example.config/db.properties
Any inputs to understand this would be of great help.

deploy.env is either environment variable or system property available to the JVM at run time.
The classpath:/${deploy.env}/com.example.config/db.properties will be resolved at run when your war is running in the container.
Set deploy.env=whatever in the shell from where you starting the tomcat or set in the environment of the user which starts the tomcat.
mvn clean install -Ddeploy.env=local here the deploy.env system property is available at build time. This will not replace the value of your spring config.
classpath is where all your classes and libraries bundled in the war are available along with the tomcat libraries. The spring property configurer will look for the db.properties file in the classpath at location e.g. /local/com.example.config
Spring documentation to learn more
Some explanation on my blog post

As stated in the Oracle Web site: The CLASSPATH variable is one way to tell applications, including the JDK tools, where to look for user classes.
That classpath: is referring to that location in particular, whatever it is, so it will start looking for those resources defined by Spring from that location and on, until it finds the first match.
Also, if you have that as a property in Maven, the value can be replaced with the right plug-in and configuration; not quite useful when you want a build that can be used with many values within those .properties files for different environments.
You can use other prefixes as file:, http:, etcetera. But you are just wondering about classpath:.

Which directory is the .properties file located for OOTB ATG Handlers (i.e. ProfileFormHandler)?

I'm working to debug a custom FormHandler that extends ATG's out of the box ProfileFormHandler and want to know if any of the methods (as well as which ones) were overridden by the custom java code. I'm having no success with finding where the .properties file lies in correlation with the ProfileFormHandler.java file.
The custom FormHandler is named "MYKProfileFormHandler.java" and is located at the filepath myk/userprofiling/MYKProfileFormHandler.java

Once the server comes up, use the dyn/admin to find where the properties file is located. Use the following URL with your hostname and port
http://host:port/dyn/admin/nucleus/atg/userprofiling/ProfileFormHandler/?propertyName=serviceConfiguration
On this page, you'll find the properties configuration at different module layers. You'll find the properties setup in your application towards the bottom. It will look something like this:
/u02/oracle/domains/servername/Domain/servers/instancename/tmp/_WL_user/Estore/qwo6y/war/WEB-INF/ATG-INF/DCS/config/config.jar/atg/userprofiling/ProfileFormHandler.properties
This is the temporary location where your application server (in this case weblogic) would extract it for its use. But this helps you to find which module has this jar. In the above example, DCS is the module.
Like bated had mentioned, you'll see that in the config.jar inside your built EAR.
Also, I am assuming that you've the source code. Just search for ProfileFormHanlder and you can find it. Please note that even though your custom formhandler is MYKProfileFormHandler, the component is still ProfileFormHandler.

To view all configuration applied to any component (e.g. a form handler) open up dyn/admin and locate the component you are searching for (http://localhost:8080/dyn/admin/nucleus/atg/userprofiling/ProfileFormHandler/) then select 'View Service Configuration'.
This will provide the path to where the config exists and the order in which the config is applied to your component.

Tomcat shared loader not taken into account

To precise the context, I am using Eclipse with its workspace metadata for my Tomcat 7's configuration.
I have this line in my catalina.properties :
shared.loader=${catalina.home}/shared/conf
Which, should load all the files contained in ${catalina.home}/shared/conf before all the files contained in my web application (WEB-INF/classes).
But this is not what I observe, the files contained in my application always override those in my shared loader (ie. log4j.xml, etc.).
Any idea ?

First of all, Tomcat 4.1 hasn't been supported for over 4 years.
Second, you haven't read the page correctly. Look at the end of the "Class Loader Definitions" section where the search order is explicitly described.
If you want to change the delegation order then look at the delegate attribute of the Loader element. This is supported in all Tomcat versions from 4.1.x to 8.0.x.

java.lang.NoClassDefFoundError from websphere

I have a problem that I can't figure out.
Context :
was 7.0.0.19 version (with no preCompileJsp)
Caused by: java.lang.NoClassDefFoundError: org/apache/jsp/_xxx (wrong name: com/ibm/_jsp/_xxx) at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:275) at java.lang.ClassLoader.defineClass(ClassLoader.java:212) at com.ibm.ws.jsp.webcontainerext.JSPExtensionClassLoader.defClass(JSPExtensionClassLoader.java:181) at com.ibm.ws.jsp.webcontainerext.JSPExtensionClassLoader._loadClass(JSPExtensionClassLoader.java:133)
It's the only JSP that give problem, and only on a specific environment (no problem on the others environments with the same configuration) the xxx.class is well present in my profile/tmp directory with others jsp in the same directory (that all give no problem) and the filesystem is not full.
Tests
I did a copy of xxx.jsp to xxxNew.jsp in the same directory
I can access the xxxNew.jsp without any problem (so there is no coding problem)
So I did a mv from xxx.jsp to xxx1.jsp and had no problem to access the jsp new named
I deleted the xxx.class in the tmp directory
I did the mv back to the first name (xxx.jsp) and still get the error with a newly xxx.class in the tmp directory.
Is there a class cache anywhere in websphere that could explain this ? (no cachespec.xml for dynacache found in the war module).
Why Websphere try to find a class from the org.apache.jsp package and not from com.ibm._jsp ? (how the AS choose the mapping from the URL to the classes ?)
Thxs !

Make sure you are not including in your webapp classpath any JSP engine or other implementation of standard JSP libraries that might be incompatible with WebSphere's runtime. Also, once you delete all potentially incompatible jars, try deleting the generated classes from JSP compilation (which are under {WAS_HOME}/AppServer/profiles/{YOUR_PROFILE}/temp), so recompilation would be triggered and discard any stale .class generated with a previous classpath state.
It would be helpful if you posted the list of JARs in your app's classpath.

Try changing the web application class loading policy on the WAS console: PARENT_FIRST / PARENT_LAST.

this bug is due to websphere incorrect log : the original exception is not displayed.
You should check for instance if there is no missing jsp tag libraries in your page.
See https://www-01.ibm.com/support/docview.wss?uid=swg1PI09596
Regards.