For my JEE 3.1 application I have a SFSB for which I have set a specific timeout. I need to have easy access to this value to allow it to be easily configurable.
First I had the annotation in my SFSB class:
#StatefulTimeout(value = 2, unit = TimeUnit.HOURS)
This works as expected. But I need this value to be (easily) configurable. Therefore I removed the annotation and placed the following xml in my ejb-jar.xml. Again this works as expected.
<session>
<ejb-name>MyStatefulSessionBeanName</ejb-name>
<ejb-class>foo.bar.MyStatefulSessionBean</ejb-class>
<session-type>Stateful</session-type>
<stateful-timeout>
<timeout>2</timeout>
<unit>Hours</unit>
</stateful-timeout>
</session>
But the ejb-jar.xml is packaged in a .jar which is within my .ear application deployment. Therefore my question is, can this setting be placed in the standalone.xml file of jboss?
There is no easy way to do this without an application restart.
If that is OK then you can define a system property in your standalone.xml. I recommend using the CLI or the admin console for this purpose.
You can then use property values in your ejb-jar.xml:
<stateful-timeout>
<timeout>${my.session.timeout.value}</timeout>
<unit>${my.session.timeout.units}</unit>
</stateful-timeout>
The property values can then be updated via the web console or CLI and your application restarted.
Related
Generally, I specify Tomcat properties in the application.properties file of my Spring Boot application. Is there any way to change some of those properties (which can be changed) dynamically, in the runtime? May be, by hitting an endpoint?
If not, is there any other way to make them dynamic from within the application code (and not the properties file)?
There are some libraries that can be configured both from the application.properties and dynamically as well (using endpoints). Does Tomcat provide any such mechanism?
Yes, there is. You can configure and hit endpoints to reconfigure:
https://cloud.spring.io/spring-cloud-config/reference/html/
There's a web application and a number of environments in which it works. In each environment it has different settings like DB connection and SOAP ends-points that in their turn are defined in properties-files and accessed in the following way:
config.load(AppProp.class.getClassLoader().getResourceAsStream(
PROPERTIES_FILE_PATH + PROPERTIES_FILE_NAME));
Thus the WAR-files are different for every environment.
What we need is to build a unified WAR-file that doesn't contain any configuration and works in any environment (for now, Tomcat instance) getting its configuration from outside its WAR-file.
The answer Java Web Application Configuration Patterns, to my mind, gives the full set of common approaches but with just few examples. The most attractive way is configuring JNDI lookup mechanism. As I can guess it allows to separately configure web-applications by their context paths. But couldn't find a simple (step-by-step) instructions in both the Internet and the Tomcat's docs. Unfortunately cannot spend much time on studying this complicated stuff in order to just meet so seemingly simple and natural demand :(
Would appreciate your links at the relevant descriptions or any alternative suggestion on the problem.
If its a case of simply deploying your WAR on different environment (executed by different OS user), then you can put all your config files in the user's home folder and load them as:
config.load(new FileInputStream(System.getProperty("user.home") + PROPERTIES_FILE_NAME));
This gives you the isolation and security and makes your WAR completely portable. Ideally though, you should still provide built-in default configuration if that makes sense in your case.
The approach we've taken is based on our existing deployment method, namely to put the WAR files in the filesystem next to the Tomcat, and deploy a context.xml pointing to the WAR file to Tomcat.
The context descriptor allows for providing init parameters which is easily accessible in a servlet. We've also done some work on making this work with CDI (for Glassfish and TomEE dependency injection).
If you only have a single WAR file deployed to this Tomcat instance, you can also add init parameters to the default global context XML. These will be global and you can then deploy the WAR file directly. This is very useful during development.
I've been using an embedded neo4j server in my project so far.
Now I want to try out the new bolt protocol with a standalone server, however only for my deployed application. For convenience, I still want to use an embedded database when running from IDE (permanent) or when running tests (impermanent).
In order to support this, I've migrated from the java based configuration to the use of a ogm.properties file. Depending on the environment I run in, I want to use the file which configures the respective driver/database location.
I have placed a default configuration in the root of my resources folder. However I am not able to "override" this in other environment.
In order to do that I placed a different ogm.properties in the root folder of the deployed application. This doesn't seem to work. This the mechanism that I previously already used in order to have different application.properties and logback.xml configurations.
Is this not supported by neo4j-ogm? If not, how can one achieve this? It also isn't (trivially) possible with the java based configuration.
I am a bit confused, since this doesn't sound like such an unlikely requirement...
You can use Spring Profile for this to configure different properties for different environments and you can look here.
You can use application.properties (spring.profiles.active) to load a different profile or by using a runtime argument if you are using Spring boot with CommandLineRunner.
I'm using spring mvc and tomcat as a server. I want to be able to change a jndi field that is Autowired(as String):
<jee:jndi-lookup id="someMessage" jndi-name="someMessage"/>
in one of the my services, that is referenced to conf/context.xml of Tomcat, that looks something like this:
<Environment name="someMessage" value="Change this." type="java.lang.String" />.
However, when I change the value on context.xml, this change is not reflected on my service managed by spring, unless I restart server. Is there anyway to reflect this change without restarting or redeploying war? I know there is a solution to include such a dynamic field in one of properties file and then use commons configuration library to reload the changes, but I'm looking for a solution to keep this field on my conf/context.xml...
I think that is not possible. Why don't use a property file or a static class?
As far as I know, it's impossible if you put it into the conf/context.xml of your tomcat home as the following doc shows:
StandardContext.html#reload(): If the context.xml has changed, you should stop this Context and create (and start) a new Context instance instead. -- i.e. can't achieve by original context
Reload Existing App: Reload an existing web application, to reflect changes in the contents of /WEB-INF/classes or /WEB-INF/lib. -- i.e. not reflect the change of context.xml
But you can define your app's /META-INF/context.xml, which will be packed into war and you can replace war without restart server.
I read #yorkw answer at this topic. He said:
The purpose of .properties file is to provide the capability of
configuring database connections at application runtime (for web
application, usually require restarting application container/server
after .properties file changes).
The question is if we can change properties on the fly without restarting container/server? Provide me an example please (I ask because in my demo it doesn't work, means value isn't changed).
I mean if we have some kind of admin tool than we can move all our configured settings to .properties files and change them via that admin tool.
Spring property files are designed to change the Spring Config of an application. The spring config is read when the spring container is initialised - this will form part of the application startup.
If a change is made to one of the spring config files (includes the *.properties files) the spring container would need to be reloaded to pick up the change.
Properties put into spring properties files should typically be properties that are tied to the life cycle of the application - i.e. the kind of properties that when changed require an application/spring container re-initialised - things like the database url/config etc.
So values that you want to change at runtime without requiring a restart of the application are not good candidates for placement in a spring properties file.