> Collaborative software development is a key tenet of the ASF and code > that is developed in isolation may need to come through the > incubator. Ideally, new code contributions start with a "hey, I was > thinking about ...." message and some initial discussion and then > maybe a proof of concept before starting something in a sandbox to > see it develop and talk through the design issues.
> It looks like you have a working version documented and packaged up > on the tersesystems.com site. Is the code basically in maintenance > mode or do you anticipate further development? How do you see others > contributing to the further development of the code? I have a few, mostly stylistic concerns with the code right now, mostly related to future enhancements or assumptions I've made in the code. The first is in the ConfiguratorFactory -- I return either a DOM or a Property configurator based on the suffix, and throw an UnsupportedOperationException if not found. I don't know what the correct behaviour is, but I'd like it to fail / fall through in a manner consistent with the rest of the code, and be able to handle new configurators without code modifications. This may be reaching, though. It could also use more javadoc. The second is that the LayeredConfigurator only implements the bare minimum of doConfigure methods, although it does adhere to the Configurator interface. If other classes depend on the implementation, this class may not be able to work as effectively. I don't really understand LoggerRepository, and so I've copied what I saw other code doing. I don't know how big a deal this is. substituteParameter calls OptionConverter.getSystemProperty(parameterName, "") directly. It'd be nice if there were some way to define where substitution properties came from, although the method is intentionally protected so subclasses can change that behaviour. Unit tests and integration tests are local to the system, and haven't been integrated into log4j-core. Otherwise, I'm pretty happy with it as it stands. > Please look through the IP clearance process at http:// > incubator.apache.org and see if it raises any issues. The scope of > the contribution appears to be much smaller than an incubated > project, but some of the same questions should be answered. Will do. > I did take a scan of the code, it does appear to conform to ASF > source header policy (http://www.apache.org/legal/src-headers.html). > > It also stated that it was based on log4j 1.3. log4j 1.3 development > has been abandoned. I assume that it could be modified to work with > log4j 1.2, but maybe you already have some thoughts on that. If it > were to be accepted into the LS project, any release would need to > target log4j 1.2. Okay, that's an instance where the javadoc was unclear. I was specifically targeting JDK 1.3 syntax and made a note of this because there are some features and tokenizers that would have made parsing easier. It actually targets log4j 1.2.15. Will. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
