Hosted by SourceForge |
Protomatter Free Software version 1.1.7 SourceForge Project Summary Page Released January 6, 2002 |
Why the license change? I've had lots of questions about commercial use of the libraries, and many corporations are in one way or another paranoid about the LGPL being too close to the GLP, which is quite viral. The Apache license more closely mirrors my own needs for a free software license -- it is extremely simple and clear, and it fits with corporate (closed-source) use of the library. To that end, I've decided to adopt the new license.
If you have any questions about licensing, please don't hesitate to send email to support@protomatter.com. If it takes your lawyer more than 10 minutes to evaluate the license, they are ripping you off -- it's that simple. If they are paranoid enough about things, I'm willing to co-license with select other open-source licenses in extreme cases. Argh... legalese is so annoying.
Also, this is not un-common. Other projects like JDom have done this (their license is much like mine), WebDAV has a similar license, PHP has a similar license, and of course all Apache Software Foundation projects are licensed under similar licenses. These licenses are all in essence the BSD license, mildly adapted.
It's unfortunate that what essentially happens is that each
project gets its own license, when what you really want
is to say "
Added the "minimal-syslog-jar" build target that makes a jar with a minimal amount of Syslog functionality. No XML to do configurations, and no JMX, but everything else is there. This jar is currently about 88K. You could further reduce the size if you take out SMTP suppport, JMS support, remote logging support, etc... You can make changes to the build.minimal.include.txt file to tune the size of the jar for your application (current minimum is about 52KB, but you could make it smaller by removing individual loggers that are not being used, etc).
If you were doing this before:
now you need to do this:
Other than that, configuration is exactly the same as before. If you're using the SyslogT3Startup class to start Syslog from inside WebLogic Server, the you don't need to do anything because the startup class takes care of everything.
Several users had requested these changes, and they make sense. In some cases, production environments don't want to have the most bleading-edge technologies (like XML, etc) thrown around all over the place. Also, if you're deploying syslog to a Java-enabled toaster or something, you might not want all the extra libraries needed to do XML parsing. In any case, there you go. You can still configure Syslog via an XML file and get a current configuration written back out. You can also still use API calls to configure everything.
Also, the XML parser used to parse the configuration file can now be specified using the "Syslog.xml.parser" system property. The value of that property (if used) should be set to the full classname of a SAX parser, such as "org.apache.xerces.parsers.SAXParser".
Fancy JDK 1.4 Support (at least 1.4 beta 3)
This adapter class allows you to use only JDK 1.4 logging API calls have have everything routed to Syslog without including any syslog calls in your code.
Compiling that class with the rest of the system is a bit tricky, because it needs JDK 1.4, and the JDBC connection pooling code is currently not able to be compiled with JDK 1.4 (extra methods in JDBC). So, if you want to compile it yourself, build everything else with JDK 1.3 and then switch to JDK 1.4 and build the "compile-jdk-14" target in the build file. I'll clean this up, but for now you'll just have to deal with it. The jar file that ships has that class compiled in it.
Also, at the risk of editorializing here, the new logging API is not very good. There's all kinds of cruft in there and my guess is that it's there because the API tries to satisfy too many people. A couple things that bug me:
And that's just what came to mind in the last few minutes. Still, as a colleague of mine is fond of saying "standard is better than good" -- and the new API is the standard. Still, with the adapter class, you can easily route all messages from the new API into Syslog, where you'll still have full flexibility to route messages into databases, JMS, text files, email, etc.