I'm using an embedded Glassfish 4 with Arquillian for integration tests. Until now I did not need a custom domain.xml. But now I have the need to add options for the jvm to increase memory. I could find a tag named jvm-options which is probably the right thing to use. But generally speaking: Is there a reference for all the available options of the domain.xml in glassfish? The administration guide says, it is a representation of the domain model which will probably be classes.
I want to be able to find out what an existing option in the domain.xml means and also find out what an option given in the domain model maps to in xml.
I recently had to migrate from Glassfish 2 to 4, I found that Glassfish 3 documentation for domain.xml is still valid: https://docs.oracle.com/cd/E19798-01/821-1753/6nmnef736/index.html
Related
I want to modularize a monolithic application by using Java modules (introduced by Project Jigsaw).
Unfortunately I'm currently stuck to use Java 8. I would like to build those modules (jar files) anyway, but without the feature of using a module-info.java file for declaring the dependencies and the exported API.
Some weeks ago I stumbled upon an API/framework which allows to define nearly the same things that you can do in a module-info.java file. It could be used in JUnit tests in order to enforce module's not to use the internal's of another module and that module's only can access modules they explicitly depend on.
Of course you do not have any assistence from the compiler or the IDE, but you can enforce the access by JUnit. Unfortunately I do not find the project which provides the API any more.
Can anyone help?
Btw. if there is another good approach beside a unit test, please let me know, too!
https://www.archunit.org/ is what I have been looking for.
Time and again I am faced with the issue of having multiple environments that must be configured individually for an application that would run in all of them (e.g. QA, regional production env's, dev, staging, etc.) and I am wondering what would be the best way to organize different configurations?
Would it be in the database? Different configuration files per environment? Or maybe the same file with different sections/xml tags? How would these be then deployed? Embedded within the app? Or put manually in after installation to be modified in-place?
This question is not technology-specific - I've worked with .net and Java, web-apps and desktop apps and this issue comes up time and again. I'm looking to learn different approaches to maybe adapt a hybrid to address this.
EDIT: There's one caveat that I must point out - when configuration is part of the deployed solution, it is generally installed under root user on the host. In large organizations developers usually don't have a root access to production hosts so any changes to the configuration require a new build and deployment. Needless to say this isn't the nicest approach - especially at organizations that have a very strict release process involving multiple teams and approval levels... (sigh I know!)
Borrowed from Jez Humble and David Farley's book "Continuous Delivery (page 41)", you can:
Your build scripts can pull configuration in and incorporate it into your binaries at build time.
Your packaging software can inject configuration at packaging time, such as when creating assemblies, ears, or gems.
Your deployment scripts or installers can fetch the necessary information or ask the user for it and pass it to your application at
deployment time as part of the installation process.
Your application itself can fetch configuration at startup time or run time.
It is considered bad practice by them to inject configuration files in build and compile times, because you should be able to deploy the same binary file to every environments.
My experience was that you could bake all configuration files for every environments (except sensitive information) to your deployment file (war, jar, zip, etc). And you design your application to take in an extra parameter when starts, to pickup the right sets of configuration files (from your extracted deployment file, or from local/remote file system if they are sensitive, or from a database) during application's startup time.
The question is difficult to answer because it's somewhat vague. There is no technology-agnostic approach to configuration as far as I know. Exactly how configuration is set up will depend on the language/technology in question.
I'm not familiar with .net but with java a popular approach is to have a maven build set up with different profiles. Each profile is specific to an environment. You can then define different properties files that have environment-specific values, an example from the above link is:
environment.properties - This is the default configuration and will be packaged in the artifact by default.
environment.test.properties - This is the variant for the test environment.
environment.prod.properties - This is basically the same as the test variant and will be used in the production environment.
You can then build your project as follows:
mvn -Pprod package
I have good news and bad news.
The good news is that Config4* (of which I am the maintainer) neatly addresses this issue with its support for adaptive configuration. Basically, this is the ability for a configuration file to adapt itself to the environment (including hostname, username, environment variables, and command-line options) in which it is running. Read Chapter 2 of the "Getting Started" manual for details. Don't worry: it is a short chapter.
The bad news is that, currently, Config4* implementations exist only for C++ and Java, so your .Net applications are out of luck. And even with C++ and Java applications, it won't make pragmatic sense to retrofit Config4* into an existing application. Because of this, I'd advise trying to use Config4* only in new applications.
Despite the bad news, I think it is worth your while to read the above-mentioned chapter of the Config4* documentation, because doing so may provide you with ideas that you can adapt to fit your needs.
Hey all,
I'm curious if you can use a jboss SAR to hold all the xml, class files, and even lib files that, if you were using tomcat, were traditionally in the /shared/classes, shared/lib locations into a SAR.
The intent is that instead of messing around in the jboss/conf/ directory to simply deploy an 'appconfig.sar' beside your actual app.war/app.ear.
Example usecase is Alfresco shared/classes/*..
thanks for any feedback!
I would say this depends on your JBoss version and the ClassLoadingConfiguration you're using. I can work, but then it can just as easily break in the next version of JBoss. JBoss 7 is very strict for example.
In general I would not rely on the specific behavior of a specific JBoss version and package my dependencies with my application. If you want to share dependencies between several .war then consider having then all in in an .ear and the dependencies in .ear/lib.
We develop web application and we are going to deploy it on JBoss.
Now we use JSF, Facelets, Webflow, JMX, Spring.
We are going to use JMS(ActiveMQ).
Maybe in the future we will use EJB3. But for near future we will not use it.
What configuration of JBoss would be better to use - web, standard, default?
And why?
Go for the smallest config that does what you need. The "web" configuration seems to have everything you need, including ejb3 support.
Remember, the configurations in the distribution are just examples. It's perfectly acceptable to create custom server configs by copying the deployers and libs around to produce a config that does exactly what you need.
I've never found the need to use anything other than default, sometimes removing some of the config. And that's included JMS, EJB, Spring, Webflow, etc.
I you are using JBoss AS 5.1.X, I recommend this book: http://www.amazon.com/JBoss-AS-Development-Marchioni-Francesco/dp/1847196829
On page 31 there is a detailed explanation about the five provided configurations.
I am trying to write some simple Java web services so we can call Java code from .NET. So far, I got a proof-of-concept working under Glassfish. Pretty straightforward when the IDE does all the work.
Now I'm really bogging down on stuff in Java that should be really simple. For example, I want to externalize my configuration so I can change stuff like connection strings/usernames/application variables/etc without recompiling.
In .NET, you would just stick some strings in the web.config file in the root of the web site and use: ConfigurationManager.AppSettings["whateverIwant"];
I can get java.util.Properties to do what I want (from a standalone client), but I can't figure out where to put the .properties file and how to get the path to it from within the web service.
I need my approach to work within WebSphere Application Server as well. Thanks!
As others have mentioned, it greatly depends on the container, but almost always dynamic configurations are stored in a database instead of XML or .properties files.
As I see that this is just like a proof of concept, here's a quick and dirty solution: (don't do this for production code) use System Properties.
Disadvantage: with every change you need to reboot the container, but you don't need to recompile the app.
To use system properties in Glassfish you can go to the section "Configuration -> System Properties" and add properties there. Then from inside your application just call
String myValue = System.getProperty("myProperty");
To get the value. All java applications support these properties, but I don't know how to configure them in Websphere.
Alas, Java EE has a giant hole in the head when it comes to application configuration.
Your best bet is to either:
use JNDI to store config in the application server environment. This is hard to do portably, painful, and an absolute nightmare for the user to do any configuration. Configuration UI depends on which app server and version is in use and may be a command-line-only utility specific to that app server.
Use the Preferences API to store your configuration, and produce your own UI to edit it. This is OK ... except that you can't control when your settings are flushed and re-inited. Some app servers will do this when your app is re-deployed, which you probably don't want.
All in all, the situation absolutely stinks. There's no clean, sensible way for an app server to provide an app with a simple properties map and UI to edit it using the app server's admin tools.
I tried to work around this using web context parameters, but found that they too were buggy. Glassfish was ignoring more than the first web context parameter that was being set, and they were hard to access without having a servlet context so you couldn't really get to them easily across the whole app.
If anyone has a better answer I'd love to hear it, because the situation as it stands seems downright amazing for a spec that's been through several major iterations.
see also: Storing and editing configuration for Java EE applications
Application configuration is unfortunately container dependent. In general you access your configuration through JNDI. The approach I've recently used was the following:
Make a database available to your app (through JNDI, use the Glassfish database "wizard"). This is part is container dependent.
Create an entity bean that deserializes your settings from the database. The simple solution here is to have something like this:
#Entity
public class Setting {
#Id
private String name;
private String value;
...
}
Then it's a question of doing em.find(Setting.class, "whateveriwant").getValue(). Alternatively, you could create a single entity bean with all the settings as attributes.
Either way, this approach reduces the container dependency to a minimum.
The best solution I've found so far is "EAC4J (External Application Configuration For Java)". I've used successfully in many projects.
Put the following code in the contextInitialized method of a ServletContextListener:
ServletContext sc = sce.getServletContext();
Properties systemProps = System.getProperties();
String path = sc.getRealPath("WEB-INF/application.properties");
systemProps.load(new FileInputStream(path));
This reads from application.properties from the the WEB-INF folder of your web app when it starts. This will require a restart every time the configs change, but in my opinion, that is as it should be.