Develop Reference

WildFly controlling ejb transaction timeout via jboss-ejb3.xml

I try to increase ejb transaction timeout in WildFly.
There are 3 options to do it:
via standalone-full.xml file, affects all components globally
via #org.jboss.ejb3.annotation.TransactionTimeout wildfly specific annotation. Requires code changes.
via jboss-ejb3.xml file.
The last option does not work with Wilfly 10. The example could be taken from Specification of Transaction Timeout in the Deployment Descriptor
The problem is that the documentation belongs to version 9. Beginning from WF 10, I do not see this timeout-specific section in Wilfly 10 jboss-ejb3.xml Reference
Also existing examples refers to transaction xsd schema, but it does not exist anymore, see jboss xsd existing schemas.
In the github repo it could be found: github transaction xsd schema
Does this ability to control transaction with the option #3 still exists? Or what do I miss with it?

How to change Cookie Processor to LegacyCookieProcessor in tomcat 8

My code is working on tomcat 8 version 8.0.33 but on 8.5.4 i get :
An invalid domain [.mydomain] was specified for this cookie.
I have found that Rfc6265CookieProcessor is introduced in tomcat 8 latest versions.
It says on official doc that this can be reverted to LegacyCookieProcessor in context.xml but i don't know how.
Please let me know how to do this.
Thanks

You can try in context.xml
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
reference:
https://tomcat.apache.org/tomcat-8.0-doc/config/cookie-processor.html

Case 1: You are using Standalone Tomcat & have access to change files in tomcat server
Please follow answer by #linzkl
Case 2: You are using Standalone Tomcat but you don't have access to change files in tomcat server
Create a new file called context.xml under src/main/webapp/META-INF folder in your application & paste the content given below
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>WEB-INF/tomcat-web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
</Context>
When you deploy your application in Standalone Tomcat, the context.xml file you placed under META-INF folder will override the context.xml file given in tomcat/conf/context.xml
Note: If you are following this solution, you have to do it for every single application because META-INF/context.xml is application specific
Case 3: You are using Embedded Tomcat
Create a new bean for WebServerFactoryCustomizer
#Bean
WebServerFactoryCustomizer<TomcatServletWebServerFactory> cookieProcessorCustomizer() {
return new WebServerFactoryCustomizer<TomcatServletWebServerFactory>() {
#Override
void customize(TomcatServletWebServerFactory tomcatServletWebServerFactory) {
tomcatServletWebServerFactory.addContextCustomizers(new TomcatContextCustomizer() {
#Override
public void customize(Context context) {
context.setCookieProcessor(new LegacyCookieProcessor());
}
});
}
};
}

Enabling the LegacyCookieProcessor which is used in previous versions of Tomcat has solved the problem in my application. As linzkl mentioned this is explained in Apache's website https://tomcat.apache.org/tomcat-8.0-doc/config/cookie-processor.html.
The reason is that the new version of Tomcat does not understand the . (dot) in front of the domain name of the Cookie being used.
Also, make sure to check this post when you are using Internet Explorer. Apparently, it's very likely to break.
You can find context.xml in the following path.
tomcat8/conf/context.xml
<?xml version="1.0" encoding="UTF-8”?>
<!-- The contents of this file will be loaded for each web application —>
<Context>
<!-- Default set of monitored resources. If one of these changes, the -->
<!-- web application will be reloaded. -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<!-- Uncomment this to disable session persistence across Tomcat restarts -->
<!-- <Manager pathname="" /> -->
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor"/>
</Context>

The problem is still with Tomcat9. Same process need to follow for Tomcat 9 to set the class.
Add the class in context.xml file.
If you are using eclipse to run the application, need to set in the context.xml file in the server folder. Refer the below screenshot for more reference.
Hope this helps someone.

SameSite issue in tomcat version < 8.5.47 has resolved
In Tomcat 8.5.47 and bellow (Tomcat 8 versions), setting CookieProcessor tag to enable same site (as given bellow) in context.xml does not work due to a bug in Tomcat.
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" sameSiteCookies="none" />
If you find in this situation where it is not a easy thing to upgrade tomcat immediately (which I faced recently), or if you find any other case where you just need custom processing in cookies; You can write your own CookieProcessor class to get around.
Please find a custom CookieProcessor implementation and details of it's deployment steps here.
In my case I wrote a custom CookieProcessor based on LegacyCookieProcessor source code that allows tomcat 8.5.47 to enable SameSite attribute in cookies.

As mentioned by #atul, this issue persists in Tomcat 9. It will most likely persist moving forward with all future versions of Tomcat, since this is the new standard.
Using the legacy cookie processor (by adding the line above to the context.xml file) is working well for us. However, the true 'fix' is to adjust how your cookie is formed in the first place. This will need to be done in your application, not in Tomcat.
The new cookie processor does not allow the domain to start with a . (dot). Adjusting your cookie (if possible) to start with a value other than that will fix this problem without reverting to the old, legacy cookie processor.
Also, it should be obvious, but I didn't see it mentioned above: after updating the context.xml file, you need to restart the Tomcat service for the change to take effect.
Cheers!

How to run two WAR files with different spring profiles on a tomcat server?

I would like to run my spring application two times, in parallel, on the same tomcat server. One time with a production profile and one time with a dev profile.
I also would like to build one single WAR for the two profiles.
I've successfully integrated profiles in my application with #Profile annotations. I've successfully deployed the two WAR files on my tomcat server.
What I need is a mean to activate a different profile on each of theses two applications, with the constraint that these two applications use a copy of the same WAR file and that the two applications should run in parallel.
So WebApplicationInitializer and web.xml seem not an option.

For the record:
To activate the dev spring profile on the application in application-dev.war
Create a file <CATALINA_BASE>/conf/Catalina/localhost/application-dev.xml
With the following content:
<Context>
<Environment name="spring.profiles.active" value="dev,server" type="java.lang.String" override="false" />
</Context>
This set the spring.profiles.active property to dev,server for the application run by application-dev.war.
Thanks to this answer: https://stackoverflow.com/a/26653238/1807667
P.S.: With autoDeploy=true in server.xml, the configuration files disappear on tomcat restart.
Solution is to add <Context reloadable="true"> in <CATALINA_BASE>/conf/context.xml but beware that according to documentation :
This feature is very useful during application development, but it
requires significant runtime overhead and is not recommended for use
on deployed production applications.
and moreover using <Context reloadable="true"> does not solve fully the issue the configuration files still disappear for some restart.
P.S.2: There is no docBase attribute in the Context element, see this question.

Why is Realm setting required in Server.xml and not web.xml

I am working on a Java application for a while. I primarily work on .NET Platform. Although I feel lot of concepts are common between these two platforms but there are few areas where I am finding some issues related to the configuration.
I am working on Authentication and Authorization and thought I would get something similar to Membership APIs of .NET in JAVA. Closest which I got was using j_security_check. I also got to know about JAAS but think it is little too deep for me to dive into.
I have created the user and role tables in the database and now I have to specify the JDBC Realm settings somewhere. I am using Tomcat 7.0. In most places, it's mentioned that I need to specify the realm setting in the server.xml.But wouldn't that apply to all web application deployed on that server since it would become a server level configuration ?.
On a site I even saw a developer mentioning about context.xml but again can't see a standard document that mention about using this XML file for setting JDBC realm
In.NET, We always put Membership settings at the web.config level and not Machine.config.
Totally Confused on this. Looking for some light on this.

Why is Realm setting required in Server.xml and not web.xml
This is not true, you can define it in your webapp as well, but then only in a servletcontainer-specific configuration file, such as /META-INF/context.xml in case of Tomcat. It cannot be definied in /WEB-INF/web.xml because it's specific to the standard Servlet API, not the servletcontainer implementation.
But wouldn't that apply to all web application deployed on that server since it would become a server level configuration ?.
That's correct. This is not recommended if you have no control over the server or if you don't want to publish the realm through other webapps.
On a site I even saw a developer mentioning about context.xml but again can't see a standard document that mention about using this XML file for setting JDBC realm
You can specify it in webapp's /META-INF/context.xml. See also Tomcat's own documentation on the <Context> element:
Defining a context
It is NOT recommended to place <Context> elements directly in the server.xml file. This is because it makes modifying the Context configuration more invasive since the main conf/server.xml file cannot be reloaded without restarting Tomcat.
Individual Context elements may be explicitly defined:
In an individual file at /META-INF/context.xml inside the application files. Optionally (based on the Host's copyXML attribute) this may be copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to application's base file name plus a ".xml" extension.
In individual files (with a ".xml" extension) in the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory. The context path and version will be derived from the base name of the file (the file name less the .xml extension). This file will always take precedence over any context.xml file packaged in the web application's META-INF directory.
Inside a Host element in the main conf/server.xml.
(emphasis is not mine, it is already as such in Tomcat's documentation)

How do I slim down JBOSS?

We're using Jboss, but we are really only using its JMS stuff. So, is there a way that I can trim down what's loaded when Jboss starts?

You can go for a servlet container (Tomcat) + a JMS provider (ex. ActiveMQ), without using an application server at all.

From 6 years ago, here's a blog entry about configuring JBoss with "just the right stuff."
I haven't used JBoss in a few years, but in v4.0, you could just drop the desired jar files into the deployment directory, and JBoss would load... only those jars.

The correct way to do this, is making a separate profile on your JBoss server that contains only the things needed to use JMS. JBoss v5 comes standard with several profiles: minimal, default, standard, all and web. Each of those starts other services. If you do not specify any profile, you're using the "default" profile.
You can create your own profile starting from a copy of the minimal profile and adding services as needed for JMS support.
The JBoss documentation contains a bit of information on what the files in those profile directories are used for. See Jboss server configurations.
You didn't specify which version of JBoss that you are using. Keep in mind that there are some changes in the configuration between JBoss v4 and JBoss v5/6. The referenced documentation in the answer from Cheeso points to JBoss v4.