I am trying to migrate from log4j1 to logj2.
I have a WLS server with two ear files. Ear1.ear and Ear2.ear. Both have similar code and for logging, they use the same logger name. In log4j1, there were two different config files loggingconfigEar1.xml and loggingconfigEar2.xml writing to ear1.log and ear2.log respectively.
I am trying to implement the same in log4j2, but not able to find an easy way out. Is it possible to have two different ears with same logger name have its own individual log files. Right now, I am initialising the config file through the System Property log4j.configurationFile and it does not work.
The only other option that I can think of is, have separate logger names for the two ears. But that would involve code change in quite a few places and I want to have it as a last resort option.
FYI, there was a lot of customisation done for log4j1 which I have avoided in the migration either by scrapping the functionality or by rewriting code. I am not sure how exactly this separate logging was achieved in log4j1.
Related
change a config.properties file in a jar / war file in runtime and hotdeploy the changes ?
my requirement is something as follows, we have a "config.properties" in a jar/war file , i have to open the file through a webpage and after the user has made necessary changes to it, i have to update the "config.properties" in jar/war file and hot deploy it. can we achieve this feat ? if so can you please point me to relevant sites/documents so that i can jumpstart on this.
I will strongly recommend your architecht rethink this solution. What you describe should be done through JNDI or a similar technique, not through reloading properties.
Deployments should be considered static - that any given web container allows for magic trickery should not be depended on, and WILL break some day (most likely at the most inconvenient time).
You've got a couple of problems off the top of my head:
ensuring that nothing is holding static references to a java.util.Properties that has previously loaded your config.properties file.
most servlet engines will unpack your war to a working directory so the properties file you load won't be the one in the war, it will be the unpacked one. This means your changes
will be overwritten when you restart the servlet engine because this is typically one of the points the war is unpacked.
While these problems aren't insurmountable I've always found it much easier to implement this sort of behavior by storing the properties in JNDI (as Thorbjørn suggests) or a database (while being careful about the static references I mentioned in point 1).
The JNDI/database solution has the nice side effect of easing deployment into multiple environments because each typically has it's own registry/database.
Even that I agree with the comments explained before, I could suggest one solution:
Apache Commons Configuration extension gives you the posibility to do something like:
config.setReloadingStrategy(new FileChangedReloadingStrategy());
That could make the trick to change the configuration file on a runtime basis with no code at all.
However, like JNDI and other methods of web application configuration, the security is a concern. Be careful on which parameters you can/must be able to configure.
I'm using icinga/nagios to monitor a huge bunch of servers and clients. So I wrote some scripts to dynamically generate my host configs.
No I'm not so really glad with this big construct because sometimes I want to have on or two extra service checks on a certain server.
In this case I can create a "manual" config but I also want all the 20 normal checks....
Now I wonder if there is a possibility to add a "include" directive to a config? Like:
include "../manual/configs/hostname.cfg"
So I could add an extra file to every dynamically created config and fill there some extra checks if not I leaf it blank.
Thanks for help
Regards Andreas
Not possible with Nagios/Icinga 1.x but Icinga 2.x
I'm not sure if title is good for a problem I'm facing, so feel free to correct it if there is better term for that situation.
Basically I'm struggling with the follwing problem. I work on a project on two different workplaces. The problem is that I have two different connection strings in my Web.config file because I have different server names. So it's a pain to work under source control.
So I've tried to use config transformations, but they only work then you do publish, and not then you run locally with F5. Is there any solution for this?
Here's a nice extension that should do it: SlowCheetah
Background
We have an existing webapp, built with Struts 2 and Freemarker, of which I’ve created a variation by copying some of the code and templates. Kludgy, but manageable. We will however soon be making quite a few other variants (which need to be individual WARs), making copying untenable. My thought is to instead put all the shared stuff into a jar included with each webapp: the common files could be maintained in one place, and even better a given webapp could override files from the classpath. So far I've been able to do this with the code, but the Convention plugin is making it difficult to do the same for the Freemarker templates.
Problem
Thus far our webapp has relied on Convention to find the Freemarker “action results” (i.e. templates) for actions at application start-up, saving us from having to tediously annotate each of them. If I've traced things correctly, the class DefaultResultMapBuilder is responsible for finding the actions results; in particular, the method createFromResources looks in the webapp and then on the classpath for template files matching our actions.
This is exactly what I want – except that we put our templates under /WEB-INF to protect them from outside access (using the struts.convention.result.path constant in our Struts configuration). This has worked fine until now, with ALL template files located under /WEB-INF, but it’s not working with files also on the classpath. DefaultResultMapBuilder can certainly find files on the classpath, but only when webapp templates are under the context root directly, as any classpath templates have to be in a package structure equivalent to the directory structure of templates under the context root. For action results to be found when “struts.convention.result.path" starts with “/WEB-INF/” would require a root package called “web-inf” – but of course hyphens are not allowed in package names.
(Note that this issue is independent of the TemplateLoader classes that are later used to actually grab the template files. The loading process is readily configurable to look in many places – but the app never gets that far if the ‘action results’ are not found at startup. It would be nice if both processes used the same configuration...)
Solutions?
So… I could move all our templates outside of /WEB-INF but really I’d rather not. Or I could provide specific annotations for each action class, and again I’d rather not (and indeed it might suffer from the same issue).
Or I could make my own implementation of ResultMapBuilder by copying and very slightly changing DefaultResultMapBuilder (every member in the latter is private, so I can't extend the class and change just the relevant parts – alas!), and then figure out how to override the "struts-plugin.xml" Struts config file (to change the org.apache.struts2.convention.ResultMapBuilder bean), and thus I could get Convention to ignore "/WEB-INF" when looking on the classpath. Or perhaps better, to always prefix the path with "/WEB-INF/" when looking in the ServletContext.
But maybe there's an easier way? Some undocumented bit of configuration magic?
I have a symfony application with two different applications (frontend, backend) but there is one action in common. Now I have duplicated its code in both apps but I don't like that at all.
Is there a way to reuse an action in multiple symfony applications?
The easiest way would be to make an actions base class in lib with the shared methods/actions. Then the modules that need to use this functionality can just extend that base class instead of sfActions.
You could also probably just use an event listener on method_not_found of sfComponent. But that may not work as expected if the method is an actual action (and it would also be available in all modules and all components without some special detection logic).
The most complicated way would be to make a Plugin. Of course that would require making the logic that works with any models dynamic so it can be configured or isolating the relevant parts of the schema to the plugin's schema.
Two more options:
1) if your are on Linux, make a symlink to your actions.class.php or even whole module, if you share the same templates.
cd apps/backend/modules/name
ln -s ../../frontend/modules/name name
2) if you have not gone too far in development, re-factor your project to have only ONE application (my favourite).
If you want to share a module (and hence also it's actions), the proper way is to create a plugin.