Can I simply replace log4j-core-2.x (e.g. 2.8.2) with 2.17.1 without breaking backward compatibility? In other words, is Log4j project following Semantic Versioning?
Log4J official changelog does not provide any clear statement on that. But this would be a dramatic simplification in the remediation process.
Bonus question: is this also true for log4j-api-2.x?
There has been some API breakage in log4j-core, so it is not strictly semantically versioned. The only one I am aware of is:
The ConfigurationFactory#getConfiguration methods got an additional LoggerContext parameter (see LOG4J2-1547). This can prevent a Log4j upgrade in old Spring Boot 1.2.x versions (see this question).
However, this might be the only exception to semantic versioning, so you should upgrade the library and see if everything works.
Related
How do I attach logback to smartfox server?
smartfox uses log4j by default. How can I shift logging of my extensions/all of smartfox to logback?
I've tried this but this is failing with this error cause it has already boud to log4j I guess.
SmartFoxServer 2x uses Simple Logging Facade for Java (SLF4J) for logging. The very purpose of SLF4J is to provide a facade over the logging framework so the user can replace one logging framework with another. In your case log4J with Logback. I'll first explain how SLF4J works and how you can change one logging framework with another and briefly discuss some caveats. Then I'll cover some SmartFoxServer specifics.
Simple Logging Facade for Java Architecture
SLF4J provides API which serves as facade (abstraction layer) over the actual logging framework. This allows the user to easily switch between frameworks on deployment time without the need to change the code. But it also means that SLF4J on its own is not enough - the default implementation is no-op. In order to actually log anything you need actual logging framework (such as log4j or logback) and so called "binder" which servers as a bridge or adapter between SLF4J and the logging framework.
Swapping Logging Frameworks
The SLF4J User Manual provides detailed explanation on how you can swap one framework with another during deployment time. In short you just need to delete the old binder and logging framework and add the new binder and the new logging framework. To swap log4 with logback you need to delete slf4j-log4j12 and log4j jars and add logback-classic and logback-core.
Caveats
You should make sure that there is only one binder implementation in the classpath. Having more than one causes waring, not error. SLF4J would just pick one of the implementations. But I would not rule out the possibility for this to cause issues with more complex application (such as SmartFoxServer) that uses multiple class loaders. But more importantly you should make sure the SLF4J API, the binder and the logging framework versions are compatible. For example if you use old version of SLF4J with newer version of logback that may cause ClassNotFoundException. I suspect that this could be reason why you get the error you see.
Swapping lof4j with Logback as logging framework for SmartFoxServer 2x
SmartFoxServer 2x version 2.17.3 uses SLF4J API version 1.7.5. To swap log4j you need to first delete lib/slf4j-log4j12-1.7.5.jar and then add compatible version of logback-classic and logback-core jars. For example logback-classic 1.1.0 and logback-core 1.1.0.
You can delete lib/log4j-1.2.15.jar but I would rather keep it. The binder(lib/slf4j-log4j12-1.7.5.jar) is not meant to be used directly so it should be safe to be deleted. On other hand there are libraries that use log4j directly. I don't know if SmartFoxServer 2x uses any such library but it is safer to keep it just in case. Swapping the binder is enough for SLF4J to use Logback and ignore log4j.
Logger Output
SmartFoxServer 2x parses the logger output to provide some functionality such as the Admin Log Viewer. If you change the log output this may cause this functionality to stop working and maybe even cause other issues (on theory it should not, but you never know). There is configuration file (config/logParser.properties) that would allow you to configure the log parser, but I didn't found any documentation about it. You may try to ask on the SmartFoxServer forum. The developers are actually pretty active there so they may help.
Swapping loggers only for your extension
The instruction I gave swaps the logger for all extensions and SmartFoxServer. If you want you may try to swap them only for your extensions. But I'm not quite sure if and how that would work. Each class extension uses its own class loader but this provides isolation between extensions and SmartFoxServer and extensions, but not between extension and SmartFoxServer. What does this mean is that if you add lib.jar to Extension A classpath it would not be visible to Extension B or to SmartFoxServer code. But if you add lib.jar to the SmartFoxServer classpath it would be visible to both Extension A and Extension B. As SmartFoxServer already contains SLF4J API on its classpath you should not add it to your extension classpath. You can try to add logback-classic and logback-core to you extension classpath. But in this case you'll have two binder implementations in you extension classpath (logback and log4j from the SmartFoxServer classpath). As already discussed, I'm not quite sure how and if this would work.
Conclusion
SLF4J provides an easy way to swap logging frameworks, but there some caveats. And SmartFoxServer adds some caveats on its own. Unless SmartFoxServer team supports swapping of the underlaying logging framework (which judging by some anwers in their forum, they don't), I would be quite careful and do such swap only if there are some benefits and it is not just a matter of personal preference.
I'm upgrading Log4j-1.2.17 to Log4j2-2.12.2 in my project.
To do that I'm using the log4j-1.2 bridge.
In old version I use property file to configure log4j.
After upgrade everything looks ok, no errors, no warnings. But logs don't appear in file pointed in properties file.
I realized that PropertyConfigurator.class exists in log4j-1.2-api.jar, but methods don't have implementation.
empty PropertyConfigurator.configure(Properties properties)
Can you explain me that?
Which configuration syntax is correct when I use log4j-1.2-api.jar? log4j or log4j2?
Prior to Log4j 2.13.0 log4j-1.2-api only provides compatibility for applications that used the log4j 1.x API for logging. The Log4j 2 configuration is still used as all logging calls are redirected to Log4j 2. So only the Log4j 2 configuration syntax would be valid.
Many of the old log4j 1.x internal classes are also present because many applications were using them in an attempt manually manipulate logging, much of which probably isn't necessary with Log4j 2.
In Log4j 2.13.0 the log4j-1.2-api was extended to provide experimental support for Log4j 1.x configuration files. You would have to compare your log4j 1 configurations with the documentation to determine if that support will work for you. However, the Log4j 1.x PropertyConfigurator still will be a no-op even with the compatibility support.
Semantic versioning brings the follow approach:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards-compatible manner
PATCH version when you make backwards-compatible bug fixes
However a frontend project doesn't have an API, its doesn't break compatibility of usage, then, what the arguments to change the versions in frontends?
Please, sugestions.
Proposal
Given the importance of the installation-requirements of an application to installer-users, I propose that semver be used to version end-user applications using the installation-requirements as the public API with installer-users as the consumers of this API.
In practice, increment the:
• MAJOR version when you make incompatible API changes (e.g. installer-users have to modify their infrastructure (phone/tablet/PC/web-server/firewall config/etc) in some way),
• MINOR version when you add functionality in a backwards-compatible manner (e.g. passing additional data to an already-provisioned API or adding any end-user functionality that does not affect the installation-requirements), and
• PATCH version when you make backwards-compatible bug fixes (e.g. fixing any end-user bug that does not affect the installation requirements).
By treating the installer-users as the consumers of an end-user application, and the installation-requirements as the public API, I believe that semver does make sense and is valuable as a communications mechanism for end-user applications.
https://medium.com/#u_glow/making-sense-of-semantic-versioning-for-end-user-software-applications-a3049d97478b
Are there any plans for the ServiceStack packages to start using the SemVer standard? We just had an unfortunate circumstance where we were broken by the interface breaking changes introduced in 4.0.44 from 4.0.43 around OrmLite.
We are a sizable commercial customer and have a custom implementation of a OrmLiteDialectProvider for one of our DBMSs, it all seemed good upon the initial upgrade in our web application, however as part of testing the changes around type converting broke our system. This wasn't initially evident as part of the upgrade because our custom implementation is in a NuGet package which overrides OrmLiteDialectProvider.ConvertDbValue on version 4.0.38 which is now gone. There were no binding issues because it is only a minor version difference.
NuGet adopted SemVer back in version 1.6.
Having the SemVer standard would make it a lot easier for us to know when interface breaking changes have been made, without having to dig through the Release Notes page.
NOTE: The release also didn't indicate that the old method had been removed and upgrading would break any custom implementations.
UPDATE FROM RESPONSE
Anyway, fair enough answer. I can appreciate it would be difficult to track each package individually. In our case we wrote a custom dialect provider as we have a legacy DBMS that wasn't supported and this appeared to be the way we were supposed to add the support. We wanted to use ORMLite because we use the rest of ServiceStack and it's a fantastic product.
The new way to support the types is a great improvement and actually made our implementation easier.
We actually ran into this issue because we do always keep our ServiceStack packages inline and were upgrading the ASP portion for some fixes to the WSDL generation and this came along as part of our upgrade.
ServiceStack adopts a single rolling version for all NuGet packages which all share the same Version number. Of all ServiceStack's 60 NuGet packages it's likely there's a breaking change to at least one of the packages so semver would be useless, you should also never mix and match different versions of ServiceStack together - when you upgrade, upgrade all packages to reference the same package versions. We do aim to keep user-facing breaking changes to a minimum, by looking to deprecate old API's first, maintain parallel API versions for a while then list the new API's release notes.
IOrmLiteDialectProvider is not a user-facing interface
However IOrmLiteDialectProvider is not considered a user-facing interface since it should be extremely rare that anyone implements their own custom provider. It's also the interface for specialization for all RDBMS's and often changes with every release to support new features, internal refactoring, optimizations, etc. E.g. implementing Type Converters was a major internal refactor that required changes to IOrmLiteDialectProvider but did not affect OrmLite's external user-facing API, later releases includes optimizations requiring further changes, again this doesn't affect OrmLite's external user-facing API.
SemVer won't help here, every ServiceStack version potentially has a breaking change in some of the packages and we have no intention to complicate each release by versioning each of the individual packages differently. The issue you're having is depending on an unstable Interface that's not intended for customization. It's not treated as a user-facing API so we don't try to maintain compatibility with existing versions or publish breaking changes which happens nearly every time we add features / optimizations to OrmLite. You should instead check the commit history of
IOrmLiteDialectProvider for any changes to this interface.
I'm going to upgrade my company's subversion server from version 1.6 to 1.7. The server runs on linux (Ubuntu AFAIK).
I've read all those:
Subversion 1.7 release notes
I've also read those posts:
subversion-client-version-confusion
how-to-upgrade-svn-server-from-1-6-to-1-7
Here and now, I know how to perform this. It's not a big deal. What concerns me the most is the current hooks infrastructure. There are several scripts in bash and perl.
As for now I've found no information referring hooks infrastructure changes, but maybe there are some known issues I missed? Is there anything against the upgrade I should know?
PS: Try and see what comes method is absolutely unavailable. I'd like the upgrade to be as fluent as possible. Repository users shouldn't even notice any changes. I can't allow myself any failure in that matter.
The Subversion compatibility guarantees promise that your hook scripts are called exactly the same in 1.6 as in 1.7. In 1.7 (and future versions) more arguments can be passed to scripts, but the old arguments still match the old behavior. So if you created your scripts like the templates, to ignore 'extra' arguments you shouldn't see a difference.
Subversion 1.7 didn't change the repository format since 1.6, so you can even (accidentally) use the svnlook from 1.6 to access the repository after upgrading.
Try and see what comes method is absolutely unavailable...
Yes, the try and see what comes method is available. You build a copy of your Subversion 1.6 environment, make the Subversion 1.7 changes, and test until everything is correct.
I don't see how you can accomplish your goal of a quiet upgrade unless you copy and test.
I guess it depends what you do with your hooks...
If your hooks are using svnlook, you should have no issues. If you're using an API (like the Python API), you probably are also okay as long as you're doing svnlook type of stuff.
Where you might start heading into problems is if you poked and prodded where you weren't suppose to poke and prod. For example, instead of doing svnlook, you do svn. There are a couple of places where the parameters have changed. Also, if you did an svn checkout (an absolute no-no in a hook) and then looked in the .svn directories, you'll get a surprise. Follow the rules, color in the lines, and your hooks won't have any issues.
I don't know of any issues from Revision 1.1 to revision 1.7 that should affect well behaved hooks hooks, and I suspect that you will not have any issues as long as we are still in Subversion 1.x. When Subversion 2.x comes out, all bets are off.
Yes, there have been some changes in how hooks work. The start-commit hook has an extra field that wasn't in versions 1.4 and earlier (The capabilities field), but nothing that would affect current hooks. And, in either Subversion 1.5 or 1.6, users now can set revision properties when doing a commit. These don't affect current hooks, but might be features that you want to incorporate in your current hooks.
The upgrade has been performed and succeeded. Subversion server was updated without issues. Hooks were designed without any hacks or slashes, respecting the rules and common sense. It was risky but promising and came out profitable (checkouts are light-speed now).
Just for sake of completeness: there was a consecutive centrally managed client upgrade. And there were issues, however not critical and predictable. After transition svn client 1.6 -> 1.7.7 working copy format changed. Every existing working copy had to be manually upgraded (or wiped out and checked out clean again).
Server upgrade is safe though.