I am updating some software from log4j1 to log4j2. It uses PropertyConfigurator.configureAndWatch(String configFilename, long delay), for which I do not see any corresponding class or method in log4j2.
How do I update this to log4j2? What's the most straightforward way?
Do I have to make my own implementation of configureAndWatch, in a class inheriting from ConfigurationFactory?
I found this answer in the log4j2 user's guide.
So the configureAndWatch time can be set in the configuration file via the monitorInterval attribute.
Unfortunately this doesn't solve my situation as the configureAndWatch call I am trying to update to log4j2 occurs within a conditional. So though the monitorInterval attribute can be set in the properties file, I still do not see how to set the value conditionally based on runtime variables.
Related
In JSF sources I found the logic of defining character encoding via facelets.Encoding attribute, which can be available in FacesContext.getAttributes()
See FaceletViewHandlingStrategy#getResponseEncoding method for details. How can I define this attribute for instance of FacesContext? I tried to define it via context-param in web.xml, but it's not working. And also I didn't find any reference about it in JSF documentation.
The main reason why I want do this, it is overriding of javax.faces.request.charset value. I don't want define a special filter for my application the order to define not UTF-8 encoding. Because my application contains a lot of WAR packages inside of big EAR.
I want to send log messages to several files (i.e. different appenders) based upon some property of the message.
The problem is that each appender needs to specify quite a verbose layout (that contains a compication conversionPattern and a couple of converters). I have ended up duplicating this configuration in each appender. This works but is not ideal as it makes the config much longer than I would like as well as the pain of having to update 3 complicated bit of configuration when the layout changes.
I want to be able to define the layout once and have all my appenders refer back to that one definition (in the same way that several loggers can refer to the same appender). But perhaps there is a better way to achieve my goal of reducing duplication in the configuration?
My google-foo is weak and I could not find an answer. Can anyone here help?
TIA.
I am sorry but unless you are ready to code your own Layout class there is currently no way to skip on the copy-pasted configuration.
You can inherit from the LayoutSkeleton to get started, and either build your layout in code or use an alternate configuration file (I don't think that log4net would be kind to a dangling layout configuration in its config file)
I was asked to move from properties style configuration to xml style. The process itself is straightforward and it is not causing me any trouble, I was simply curious why I got asked this and I looked for the reason. I found this nice post Why chose XML over properties files for Log4J configuration? (more than 3 years old but still the most informative I could find), which was pointing pointing to this even older tutorial. They state
Properties can be defined by a properties file or by an XML file.
Log4j looks for a file named log4j.xml and then for a file named log4j.properties. Both must be placed in the src folder.
I checked it out and, contrary to the statement, found out that Log4j looks first for the properties file and in a second time for xml. In fact, if I keep both in the same folder, the output is formatted according to the properties file. So, am I misunderstood the statement? Is it simply wrong? The statement has been made for log4j 1.2.14 while I am on log4j 1.2.17, is it possible the log4j team changed the priority? I couldn't find any related documentation, but it will be a strange trend inversion since the xml looked to be the preferred way to configure log4j
Have a look at the JavaDoc. The documentation of the PropertyConfiguratorClass (log4j.properties) points out that
The PropertyConfigurator does not handle the advanced configuration
features supported by the DOMConfigurator such as support custom
ErrorHandlers, nested appenders such as the AsyncAppender, etc.
So the DOMConfigurator (log4j.xml) offers advanced options.
Beside that you can have (at least a simple) validity check of log4j.xml files using the provided log4j.dtd.
If youd do not make use of the advanced features it is needless to change from properties to xml files.
What you really should think about is to change from log4j to log4j 2 beta or even
slf4j. Development of log4j has stopped and the founder of it (#Ceki) invented slf4j.
As per FrVaBe's answer, the PropertyConfigurator class does not handle the advanced features that XML can support.
It's worth noting one of the more useful advanced options (only available log4j.xml) is the ability to filter on a specific log level or range of log levels using LevelMatchFilter and DenyAllFilter
A good example can be seen here.
I want to add a new section in control panel of liferay and within that section I want to have my custom-portlet. I did it using ext. However I want to do it with hook . Is it possible ?
I don't think it would be that easy with a hook, because of the following reasons:
You can't modify in a Hook - the class com.liferay.portal.util.PortletCategoryKeys which contains the keys for displaying the different sections. The different sections are hard-coded in this class in a String array ALL.
You can't modify the logic of PortalImpl#isControlPanelPortlet() which uses the PortletCategoryKeys#ALL to determine if the request in question is for a control panel portlet.
Then you also have another method which you can't modify with a Hook and is used extensively PortalImpl#getControlPanelCategory()
Doing it with a hook:
I have not tried this but I think if you need to do it with a hook you would have to change all those JSPs which make use of PortletCategoryKeys#ALL and the methods of PortalImpl as stated above, and provide your custom implementation for all these methods in the JSP.
I would really like to know how you implemented it with an EXT may be just the steps or the methods you have overridden. So that I can try to convert those in terms of a hook.
This is as far as my understanding goes. Hope this helps.
With the advent of Marketplace, ControlPanel has a new category named "Marketplace" and that section is introduced in a plugin. However, I never checked if 6.1 GA2 introduced a new section that this plugin just fills. Check the marketplace plugin if you can find a trace of this section implemented there.
On the other hand, nobody has yet named any section that definitely required a new section (though some have asked me how to solve the same problem). For this reason, you might want to re-think the requirement and choose one of the existing sections. If you don't, at least I'd be interested in the name and purpose of the new section - I might find a first one actually justifying this kind of implementation...
I want to add 3 more methods and one field to liferay.portal.model.User class. Anyone knows how can I do this? Can I switch the class by hook like this:
<service>
<service-type>com.liferay.portal.model.User</service-type>
<service-impl>my.pack.userExpanded</service-impl>
</service>
I want to have a close look at service builder but can't find good sources which will show how to switch liferay class with my own class (cause of too many uses).
So second question is does anyone know about some good tutorial or blogs regarding this? Especially I am interested in adding extra methods and fields.
The standard Liferay Developer Documentation is good:
http://www.liferay.com/documentation/liferay-portal/6.1/development/-/ai/overriding-a-portal-servi-4
Another alternative is to add Custom Fields to User entity:
You can't modify a liferay entity. Neither you can use hook to modify these things, hook can only modify limited things as suggested by the documentation.
I don't think you can even use a EXT to modify a liferay entity.
So now the what comes to my mind remains is to create custom-fields for your field requirement and build a helper utility class which will provide you with your required User methods.
You can make the helper class available to the portal by packaging in a jar and pasting it in the global path (in tomcat [TOMCAT_HOME]/lib/ext).