On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote: > But the 'push interface' has no implementation associated with it... > > I would expect, for example that I would write an app that uses the pull > interface to get a factory, and then give that factory to my components...)
Of course it doesn't - it's an interface that has to be implemented by every component that wants to use that discovery mechansim, and by any application that uses components using it. The pull is 'popular' exactly because it has a base implementation. If you remove it - it'll not be as easy to use. > So again, I'm not advocating creating a new or different logger - just > separating the generic interface apart from the *truly excellent* > implementation of that interface in o.a.c.l. For those using 'pull', the discovery implementation is essential in order to use o.a.c.l. Those using push can ignore it. That's how pull works, the API provides the basic implementation and components use it, you can't change that without affecting people who use pull. ( by making their life harder - not as hard as implementing a push interface on each component, but not as easy as it is today ). > > does, then we automatically have another valid mechansim to get a Log in > > a servlet environment - pushed by the 'deployer' via JNDI and web.xml. > > Class.forName() also works. > > Pushed in how? Using the magical Admin interfaces for web applications, which allows you to use the descriptions in web.xml and associate real impls. with the various names ( i.e. JDBC Connections, etc ). > There are lots of things I don't have a problem with - I just don't think > they all belong in the same place... Those using pull seem to need it there - so it is easy to use. We like to log using a single import statement and one line of code ( or just one line of code ) to set the logger. If you prefer implementing a marker and require an application that supports that and configures each component - your itch, your solution, no problem with me. As long as you don't remove what I need. > So you can have multiple LogFactory implementations available at the same > time? > > I still don't get it - I looked at digester - it does the ususal > > Log logger = LogFactory.... > > > Initializer. > > Now, if there were several impls of LogFactory in the classpath, which one > wins? Digester isn't using Service.providers() approach... Each class loader may have a different LogFactory implementation. That mean each application can use its LogFactory, by just including the favorite jar in WEB-INF/lib ( or equivalent ). If any logger has the manifest - it wins. If not, we try to look for few 'well-known' loggers. If you have multiple logger implementations in the classpath (each with a service manifest ) - that's your problem, you either make up your mind or use a different mechanism, like Class.forName(). We can't guess what you want. > How do I prevent someone from using the discovery mechanism to get the > default impl? You can't. If someone wants to use the discovery - it's his choice and he'll be able to do it. But he can implement a getResource( "WEB-INF/services/org...." ) anyway in his code and get the same effect - you can't prevent that either. Our goal is not to prevent people - but to help them do what they need to. ( we could use a Factory impl that uses sandbox and Permission to fine-tune who can do what - but it's not yet implemented ). > Would this be solved if there was : > > o.a.c.gl.jar - with the interfaces, no impl > > o.a.c.l.jar - with the *truly excellent* impl with nice discovery support > > So then I could put o.a.c.gl.jar in the classpath, and discovery then won't > work... Discovery will still work - just that it'll be a bit harder to do. ( i.e. the user would have to cut&paste code from LogFactory ). But again - what's your problem, if the use wants to use pull, that's his choice. If he prefers to use push - again, his choice. If you're in a project that is using push exclusively - you can tell him he's not allowed to call Class.forName(). > No, JNDI won't always work : if no one pushes a Log into the JNDI context, > there won't be one to find, unless there is some other default > implementation in the o.a.c.l package I haven't seen... Of course, and if nobody calls your setter there will be none to use. If someone pushes the Log in the JNDI, it'll be there. Are we done with the tautologies ? > So people don't assume a specific implementation? What do you mean by 'assume' ? People should 'assume' what they read in the docs - and all documented options should work. They can then choose what particular behavior they want, and use it. > > Name one interface that doesn't > > provide a mechanism to get it ( except DOM - but DOM3 will fix that ). > > 1) Anything in the JMS spec, I believe. I don't know the details. > 2) JDBC : There are no default mechanisms in JDBC to get an impl of almost > everything... I guess 'DriverManager' is there, but that's not an > interface... It's actually a base class, like LogFactory. And it's actually the recomended method if you don't use JNDI ( which is also documented and pull ). > 3) Any java2 collections -> java.util.List, unless you count new > ArrayList(), which is different, totally different, than > ListFactory.getList() True - but java2 collections provides default implementations for all of them. > > You can't. The static accessor implements the services/ - if it have a > > bug, we can fix it. If you want a different mechansim - you can add it. > > But the static accessor must work the way it is supposed to, it's not > > replaceable. > > I see. > > That isn't a problem in something that is supposed to be a generic logging > interface? No completing implementations can exist then? We don't require you to click on a licence or pass a compatibility test. And the logging interface is Log, the static method is just a helper, and you can use any other helper you like. It's a tradeoff between 'perfect'/'pure' interfaces and easy to use and convenience. > Or have a completely different private mechanism where I have some init > method, in which one arg is o.a.c.gl.Log. > > In which case thatıs a push with a totally different semantic - the LogUser > marker interface isn't implemented - but as it's a class in a private > package or something, it doesn't matter... > > Choices, choices, choices... Nothing prevent you to do that. Except that those who want the 'default' discovery can do that if the choose to. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
