For bytecode engineering, are you suggesting that we use something like CGLIB at runtime or actually manipulate bytecode at compile time? I would definitely be against introducing CGLIB (or the like) as a runtime requirement. And, I really don't like having to "enhance" classes at compile time either. That's why I prefer Hibernate over JDO. It's a real pain having to add that step into my build process.
-----Original Message----- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 13, 2005 5:46 AM To: Jakarta Commons Developers List Subject: Re: [jcl] mocks On Tue, 2005-12-13 at 00:39 +0100, Torsten Curdt wrote: <snip> > > not sure how > > good the provides-implementation-of logic is yet... > > Ah ...I see what you mean IMHO the future is a pure specification with a null implementation. to enable logging you drop any compliant implementation into the appropriate place on the classpath or use bytecode engineering to rewire the class. the implementation could be a dynamic binder like JCL or a static binder like SLF4J. also, need to enable IoC so that frameworks can more easily adapt libraries. but need to discuss this with ceki and the other folks from logging as well as the people here... > But isn't depending on anything other than the API > jar the big flaw? In theory you should never have > that dependency and then everything should be fine. > X depends on JCL_API and Y would also depend on JCL_API. but because the API also serves as a special implementation which allows clever people to do clever things (like containers and web applications all sharing the same logging library but each can be configured as if each is in total isolation) the API jar has a habit of blowing up with a load of runtime exception when used by those who are not experts in Java 2 web application classloading or when placed J2EE containers with broken classloadering strategies. AIUI this was an intentional part of the original design (for various reasons to do with specification compliance and security wories). 1.1 takes a softer, more pragmatic approach. > > IMHO it's much cleaner if the JCL API dependency could be used > > safely by > > itself. in other words, if the basic API jar had some reasonable > > behaviour (for example, discarding all log messages) when used alone. > > I think that's the mock I have in mind. IMO that's not really a mock: since the vast majority of people will never want or need to look at logs for well tested deep libraries, it's actually probably the best default implementation. that's why i've favour the term 'null API'. > >> Removing logging via bytecode modifications would be another > >> option ...but I am not sure how feasible it is. It's definitely > >> more complicated to remove than to add things at that level. > > > > IIRC Chris Nokleberg created something that did just this > > Found his blog entry ...will give that a try. That > would be awesome! it's pretty easy to use byte code engineering to directly rewire JCL calls to call instead the favoured log system. this is a performant solution. > >>> this is ceki's preferred solution. > >> > >> I think agree with him here. > >> > >>> i prefer dynamic binding > >> > >> May I ask why? ...or point to the thread in the archive. > >> I am sure you explained that before ;) > >> > >>> (run an > >>> enhancer against the library in question which does the same job). > >> > >> What do you mean by that? > > > > sorry: should have said that i prefer byte-code enhancement of the > > library (using the logging) to compile time static binding. JCL 1.x > > uses dynamic binding. > > > > the idea is that you static bind a particular library to a particular > > logging implementation by running an enhancer. so, if you want a > > library to log to log4j, you run the log4j enhancer on the jar. > > That's sound like more effort than just throwing in a certain jar. throwing in jars sounds very easy until you start thinking about the use cases that (mostly used to) break JCL. there are a lot of nasty classloaders out there in the wild. many of these will cause difficulties for static binding too. > > a main advantage of static binding is that it's easy to explain and to > > configure. but there are some things which compile time static binding > > can't do that dynamic binding can. in particular, you can set up > > configurations with jars loaded by top level classloaders and still > > allow applications to have separate configurations. this seems like it > > was really important back in the servlet days when one target was > > commercial hosters of web applications... > > > > you can do tricks with an enhancers that can't be done at compile > > time. > > Hm... need to think about that for example: you want to use library X which uses JCL in a J2EE application. you want the application to be portable across containers and the core distribution reusable for web and ejb. your application uses Log4J (say). the J2EE classloader specification is broken and every container has it's own system. it is not uncommon for JCL to be found in container or even system classloaders. this is a very hostile environment whether you're using static compilation or dynamic binding. if you enhance library X so that ever call made to JCL instead results in a direct call to Log4J not only do you have better performance but also you don't need to worry about J2EE classloading. but it's not really a case of having to choose. static compilation time binding has advantages for stand alone applications. dynamic binding works well for servlets. byte-code enhancement is good for J2EE. that's why i think a specification and multiple implementations is the complete solution. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
