> From: Mauro Talevi [mailto:[EMAIL PROTECTED]] > > Berin, > > >That is about the extent of their commonality. I tried to get them > >to support an interface that is IoC friendly, but they kept wanting > >to do it the other way--in effect working against the way Avalon > >does things > > > uhm - not exactly what one would call a "common" approach :-(
Agreed. The underlying design is the same, the details differ--except in regards to setting the logger implementation. > >In reality, the full Avalon framework is lighter-weight. The Commons > >Logging implementation is like using a sledge hammer when a ball > >peen hammer would be called for. > > > There is in general quite a strong resistance in > learning/adopting new > frameworks if the > advantages are not clear and cut. > Also Avalon Logger is "buried" in the framework and the > perception that > people get > of Avalon is that it is a "heavy" framework - certainly > heavier than the > Commons Logging and/or Log4j. > Perhaps because they associate it the apps built on top of it. The framework part, weighing in at a mere 80k uncompressed isn't very heavy. In fact it is fairly minimalistic. I agree with the problem of *perception*. > >Keep in mind that COP (i.e. Avalon environment) has a different > >set of constraints than traditional OOP. Basically, COP forces > >you to operate within a certain subset of OOP which simplifies > >a number of design decisions you have to make. It also lends > >the benefit of VLC (Very Low Coupling) between implementations > >of components. > > > yes - and I appreciate them. but if we want the Avalon > framework and > logger to > be adopted more widely - we also need to consider that COP is not the > only way > or the dominant way. > The point I'm trying to make is if and how the two can be reconciled . In a future version of Avalon, it is something to look at. The risks of a rogue component successfully cracking a container's security through logging is minimal. > >>It would be extremely useful to have to ability to keep the log > >>interface the same and hook into the Avalon Logger. > > > >It would. It seems that any attempts with the Commons Logging > >crew to implement a brain-dead solution that can be incorporated > >into Avalon failed. Instead you have all the problems of > auto discovery > >without any of the benefit of the controlled environment that > >COP affords. > > > final words? no room for negotiation? That was my last understanding. After a while it just feels like beating a dead horse. > >In the end, if we could have one interface extend the other, we could > >have it work. To date, neither project has been willing to depend > >on the other. > > > I take this is unlikely to change:-) Very much so. Although in the future, we might be able to work some alternative out.... > The issues raised by Ceki are very interesting and quite relevant to > Avalon too, > especially the dynamic discovery. > Could it be a basis for a discussion on the Avalon5 logging framework? It could. Right now, the Avalon 4.1 logging framework (which can already use Log4J or JDK1.4) is pretty solid and very simple (AKA a brain-dead solution). > In my opinion, the issue is if a dynamic discovery mechanism of some > kind can be implemented > that is compatible with IoC and COP. > commons-logging is one auto discovery mechanism - not the only > one - and > I personally found it > appealing because it provided a facade (I had not given too > much thought > about the classloader issues). I would strongly oppose a dynamic discovery mechanism. All a component needs to know is how to get its Logger. The container is what chooses the implementation of that Logger. This works very well. One problem with a globally accessible Logging framework is the lack of control the Container has for assigning categories. One example is this: A container has two instances of a component. They are used by different subsystems and don't interact with each other. The container can currently assign different categories to the components like this: "altrmi.proxygenerator.store" "cache.object.store" The reason is because of IoC. The instances can come from the same class, and the container has the right to have more than one instance of a particular component. Using the Commons-Logging methodology, we would have no way of doing the same thing. You can drive the name according to the class name (i.e. the standard in many OOP projects), or you can drive the name according to some other category naming system you have. You *could* provide a name to the component so that it knows what the container wants it to use for the logging category, but that is particularly problematic because the component author can (and probably will) ignore the hint. Consequently it is a very weak contract. > >They strongly oppose it because they want to be the standard. > >They also don't want any dependency on Avalon whatsoever. > > > Commons-logging is not as used as log4j - if Avalon could draw in the > log4j users > it could really explode in users. Well, we can accommodate them already. > >Log4J is just like LogKit or JDK 1.4. The major issue is that > >he has received a number of support requests for Log4J because of > >environmental issues introduced by Commons Logging. > > > > I meant that Log4J doesn't require (like Commons Logging) for the > loggable component > to be LogEnabled. That is a requirement of component writing (see above). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
