On 4/5/02 4:45 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> 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. Wow - you just won't give up with this. I am not advocating removing it. I am not advocating removing it. I am not advocating removing it. Clear? In the future, I will denote the above block as '***' as to not waste bits... > >> 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 ). So that's not automatic, is it? > >> 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. Is this some sort of joke I don't get? *** <- that's the bit where I tell you that I am not advocating removing the pull model... > > 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 ). With a classloader that has available multiple implementations, which is used? The first that it finds? > If any logger has the manifest - it wins. If not, we try to look for > few 'well-known' loggers. This is what we did in Velocity a while ago - I am familiar with the pattern.... > > 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. Doesn't this get confusing? Don't get me wrong : 1) *** 2) I like the pull model > >> 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. The point isn't to stop the determined, it's to prevent the accidental. Right now, it sounds like with multiple LogFactory implementations in the classpath, you spin the wheel and pray you get the right loader. If one component uses formal discovery, they get one loader, if another tosses care to the wind and does Log logger = LogFactory.getLog() It appears that the results are really indeterminate. > > Our goal is not to prevent people - but to help them do what they need to. 'Prevent people' what? No one's goal is to prevent people from doing anything. In the case where you split up the impl from the interface, if you want to use a generic log interface, put o.a.c.gl in the classpath. If you want to use pull discovery, put o.a.c.l in the classpath. Can't see how that 'prevents people' from doing things. > > ( 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 ). Again, not trying to prevent the determined adversary, but setup an environment where expectations and assumptions are clear. > > 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. Isn't choice great? (Can I have a deterministic choice in the LogFactory? :) > If you're in a project that is using push exclusively - you can tell > him he's not allowed to call Class.forName(). Um...again, not trying to beat the determined adversary, but rather just keep things simple... > > >> 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 ? You started it, and then followed with statements like "JNDI will always wark" in the context of pull always working... > >> 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 ). And that doesn't matter - the rest have no implementation, which is what you were asking about. > >> 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. So far, we have JDBC and java2 collections as examples of where the crazy idea of generic interface actually was done, and you will get back to me on JMS, I guess. >>> 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. Where's the inconvenience? An extra jar? Your component code won't change. Your application wont' change. Your logging configuration won't change. Your discovery won't change.... > >> 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. *** I'll summarize in a separate message... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "We will be judged not by the monuments we build, but by the monuments we destroy" - Ada Louise Huxtable -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
