> [EMAIL PROTECTED] wrote: > > Wow. Ceki, I am surprised you have not commented on this yet. > > Mark, > > Be kind. Maybe Ceki also has a real life that has kept him away from > this list. I had a little extra time on my hands this past > weekend, and > I had been thinking about this idea since the first time Ceki had > pointed me to his enhancements document. So I just put my current > thoughts on paper.
I wasn't picking on anybody. I'm the last person to tell anyone to spend more time working for free on open source projects and not on the projects that pay the bills. But I don't know, Mike. Submitting useful code, writing test cases to go with it, picking up projects when you have extra time...keep that up and you might become a committer. > That's an implementation detail. I intend to use reflection > to find the > relevant o.a.l.helpers.PatternConverter that is then added to > the linked > list. If I do this right, it should be possible to create new > PatternConverter subclasses for new Pattern Ids, and to find > these new > PatternConverters in the Classpath. I haven't yet figured > out the best > way to find new PatternConverter subclasses (since they won't > be in the > o.a.l.helpers package), so any suggestions would be appreciated. I have wondered about this as well for other cases. It would be useful to have some code that searches the classpath for classes that implement a given interface/class. But I think that this code would be very time consuming, searching the entire classpath, inspecting all the classes. If you think of a good way, I think we would all like to hear about it. > > But frankly, I think that doing this is not required to > accept Mike's first > > round of changes he has submitted. > > This would be nice. I've imported the current 1.3 code to my > machine, > and I have looked at how some of the proposed changes might > affect other > classes. For example, I think that my ideas would require changes to > o.a.l.helpers.FormattingInfo. Since this class is only usable within > its package (even though the class itself is public) I don't expect > changes to it to break other code. However, I don't know if > there are > any implementations of Log4J with new classes added to the the Log4J > packages. I don't think I've seen anything in the documentation > discouraging creating classes in packages already found in the Log4J > distribution. > > Is this a situation about which I should be concerned? Do you think your first round of changes will affect the o.a.l.helpers.FormattingInfo? Can you elaborate? And I don't know what the policy is on this. Anyone can write classes that end up in the same package, and thus have access to package level classes/members. Ceki, are we trying to maintain api compatibility at that level? -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
