M question is related to this one as I have the same problem. How can I make the RollingFileAppender of log4net preserve the file extension without having to actually "patch" (i.e. create an interim build of the current trunk) log4net? How could I achieve the same thing by overriding the RollingFileAppender or creating any other extension with the least effort?
As mentioned in my comment, you're not required to "patch" or change anything in log4net. You cannot use the 1.2.10 release, though. It is a rather old build, but the PreserveLogFileNameExtension is in the current source. You only have to bring down the source and compile the dll yourself and you're good to go.
Update: I see your concern. IMO, the only way is to make a build and test it. To further your confidence you could review the current list of resolved (and unresolved) issues for 1.2.11. I would think that seeing they are not doing a major revision, changes are mainly bug fixes and additional features.
Related
In my Liferay module, I want to use Liferay's SomeConvenientClass.
What is the recommended way to find out what module provides that class?
So that I can quickly add it to my build.gradle.
Ideally it should either:
return the module's group/name/version,
or say with certitude that this class does not exist in Liferay or is not exported.
Until now I go by trial-and-error and copy/paste from build.gradle files found in the wild, but I am looking for a more reliable method.
I have Liferay installed, and the source code of the exact same Liferay version, if that helps.
I tried mvnrepository but it does not seem to return anything, example: https://mvnrepository.com/search?q=AuditMessageProcessor
Have you tried http://search.maven.org/#advancedsearch ?
For example:
http://search.maven.org/#search|ga|1|c:"AuditMessageProcessor"
This is more an option than a real thing, but this is how I normally do:
be familiar with package naming conventions used by liferay and
inside apps: api, service, web...
be familiar with the bundle structure used by liferay, as their
use of resource folders, which are not so obvious sometimes...
With that in mind, normally on github is enough to navigate: portal->(kernel/impl/services/apps)->app service/api/web...
But this is a natural process that comes when you spend your day inside the code.
Normally, online jar locators help, but quite often I just rely on my IDE.
On my IDE I have all set-up with Spring dependency management, after I extracted the dependencies using Gogo shell with a running bundle. With Gogo you will not find classes, but modules and packs will be listed. (Gogo is probably what you are looking for btw, as it is able to list with version numbers)
Bottom line, if you need a list as a picture of a running environment, use Gogo.
With regards to the master code, just do not trust it! When it comes to modularity and bundles versioning Liferay is pretty messy (read The dependency management problem here: https://www.e-systems.tech/blog/-/blogs/liferay-digital-experience-platform-review-7-0-ga4).
For your step 7, you will need to chose an api version and code against it. The apis are more stable. You can impose a limit for compatibility on you bnd file, which will cause the system to issue warnings. On your environment, you can catch api changes earlier, let's say, you can ask gradle to use a module with an version number but any patch (using the "+" sing), when you build with a fresh cache or if you change gradle resolution strategy to download you dependencies more frequently, if the build breaks, well, you will see it.
Helpful start point: https://dev.liferay.com/pt/develop/reference/-/knowledge_base/7-0/using-the-felix-gogo-shell
This is how I do, it is slow and manual, so don't hesitate to suggest other methods.
Download Liferay's source code if you don't have it already.
Run find . -name SomeConvenientClass.java. If nothing is found, you can be sure the class is not part of Liferay.
In the path to the class, find the src folder level, and go just under that, so for instance if it is modules/apps/collaboration/document-library/document-library-web/src/main/java/com/liferay/document/library/web/portlet/action/DLViewMVCRenderCommand.java then go to modules/apps/collaboration/document-library/document-library-web/.
Hopefully there is a bnd.bnd file there, open it.
If the package of the class is not in the Export-Package section, then either give up (duplicate Liferay's code into your module), or use some dark tricks. If you believe the class should be exported, you can explain your case at https://issues.liferay.com/browse/LPS-70480 for future generations to enjoy.
Module name is the value of Bundle-SymbolicName.
Version is the value of Bundle-Version.
Group is probably com.liferay, although sometimes it is com.liferay.portal, not sure how to tell.
Build. Sometimes it fails because Maven repositories are missing a version, for instance com.liferay.document.library.web 1.0.11 is not available despite being used by DXP fix pack 30. Not sure what to do in such cases except choosing a "similar" version and hoping for the best.
I have deployed a document library hook which includes many jsp files under custom_jsps.
Recently, I wanted to change folder_action.jsp, so I changed it and deployed it normally in document library portlet.
As it was expected, a folder_action.portal.jsp was created containing the original file.
However, I've noticed something strange. After stopping Tomcat both folder_action.jsp and folder_action.portal.jsp are deleted(this is not happening for the other files that come from the hook), and when it is up again a really strange thing happens. The folder_action.portal.jsp contains the changed file and the folder_action.jsp is the original file.
Has anyone met something similar ever? Any help would be appreciated.
You might run into a very nasty issue: You must only override a particular jsp from exactly one hook. If you override the same jsp from two different hooks, the scenario that you describe might happen (on undeploy). Worse: Order is not maintained, you might have some "wrong" files left over.
Find the two hooks that override the same jsp and determine which you like better (or merge the two). Find some more horror in this answer to a similar question
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)
Maybe I didn't set the correct APPORTABLE config parameters when using CoreData. I can ADD,EDIT,DELETE and List down the current records when the app is running. But when I remove it from the current running apps and tried to Open my app again all of the data are gone. Maybe setting the correct parameter would eliminate this bug I am encountering right now?
You shouldn't have to set the xcdatamodel list in the configuration.json unless you have a special apportable-specific xcdatamodel. the model should now automatically be compiled and put into the app bundle. in fact, if you were using our coredata before this change, i recommend undoing everything you have done in order to get it to work. it should just work.
as for your issue, would you mind creating a test case and then emailing it to sdk # apportable.com? it's tough to debug without a reduced test case that demonstrates the bug.
update: we didn't have hasChanges properly implemented in NSManagedObjectContext. We've implemented it better, and now the test project works. Look for it the next version of the SDK (could be a few days to a week for that), and let me know if you still have trouble.
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.