On Sat, 6 Apr 2002, Geir Magnusson Jr. wrote:
> I'm trying the Service provider approach (can't find the 'Service' class
> anywhere in the 1.3.1 docs, but that's a different issue...) by making an
> alternative impl of LogFactory and putting the proper META-INF/services path
> in the jar.
>
> I
On 4/5/02 10:30 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
>>
>> It's not that I don't like the static methods -
>>
>> I *love* your static methods.
>>
>> I adore them!
>>
>> I adore them so much, I want to write an implementa
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
> It's not that I don't like the static methods -
>
> I *love* your static methods.
>
> I adore them!
>
> I adore them so much, I want to write an implementation of LogFactory myself
> for a new kind of logger I have.
>
> Can I do that and use it
s Developers List <[EMAIL PROTECTED]>
>> To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
>> Subject: Re: [logging] Need interface... VOTE
>>
>> On 4/5/02 6:09 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>>
>>>
&
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
> Date: Fri, 05 Apr 2002 18:52:21 -0500
> From: Geir Magnusson Jr. <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
On 4/5/02 6:09 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
>>
>> I looked for docs on how to setup the web.xml for tc4 to specify my ctx
>> factory, but didn't find them when I looked. I assume they are there
>> somewhere?
>>
>
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
> I looked for docs on how to setup the web.xml for tc4 to specify my ctx
> factory, but didn't find them when I looked. I assume they are there
> somewhere?
>
Short answer: You don't configure the factory in web.xml -- that goes in
server.xml.
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
> > Replace it with what ? The javadoc for the static LogFactory.getLog()
> > is pretty clear, the method must implement what's in the doc.
> >
>
> My own implementation? (You know, that choice thing?)
So you're saying an API can never use static
On 4/5/02 4:48 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
>> I don't know if that's fair - because the application has setup and pushed
>> into the context the Log..
>>
>> In the o.a.c.l model, I can't even replace the static LogFactory.
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 factor
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
> I don't know if that's fair - because the application has setup and pushed
> into the context the Log..
>
> In the o.a.c.l model, I can't even replace the static LogFactory
Replace it with what ? The javadoc for the static LogFactory.getLog()
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 -
On 4/5/02 4:14 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 5 Apr 2002 [EMAIL PROTECTED] wrote:
>
>>
>> [snip]
>> You can still choose to ignore it - or to use a different mechanism.
>> Including JNDI - Craig may explain us if web.xml would allow
>> us to define 'custom'
On Fri, 5 Apr 2002 [EMAIL PROTECTED] wrote:
>
> [snip]
> You can still choose to ignore it - or to use a different mechanism.
> Including JNDI - Craig may explain us if web.xml would allow
> us to define 'custom' resources ( besides JDBC drivers, etc ). If it
> does, then we automatically have
On 4/5/02 3:28 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
>>> There is no "must". The static method and the discovery is a helper,
>>> nothing require you to use it.
>>>
>>
>> But from what I've heard, everyone *expects* it to be there,
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
> > There is no "must". The static method and the discovery is a helper,
> > nothing require you to use it.
> >
>
> But from what I've heard, everyone *expects* it to be there, as it's in the
> o.a.c.l jar.
Not sure I understand... The helper metho
On Fri, 5 Apr 2002, Andrew C. Oliver wrote:
> If all you're talkng about is new interfaces/classes to support the
> "push" method and this won't affect the "pull" method then why wouldn't
> you just put them in the existing package? eh? How does they're
> existance hurt me if I chose not to
On 4/5/02 1:25 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
In o.a.c.l with some implicit assumptions (which I am trying to dodge...)
>>>
>>> It's quite explicit, and your proposal seem to hava a LogFactory too.
>>
>> The assumptions
I am still +1 on adding the interface.
Scott
> -Original Message-
> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 04, 2002 3:26 PM
> To: Jakarta Commons Developers List
> Subject: RE: [logging] Need interface... VOTE
>
>
> -1
>
>
04/05/2002 12:46 cc:
PM Subject: Re: [logging] Need
interface... VOTE
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> I'm very happy to see that the Xerces folks finally learned this lesson --
> the fact that the JAXP/DOM/SAX API classes used to be embedded inside
> xerces.jar was the single biggest cause of class loader issues for servlet
> conatiners like Tomca
On Fri, 5 Apr 2002, Richard Sitze wrote:
>
> On the other hand, I DON'T like separating the interface into a separate
> jar file from the implementation (it's RAINING jar files over here). I
> WOULD be happy with building multiple jar files, each containing the
> "common" interface and a singl
On 4/5/02 12:24 PM, "Morgan Delagrange" <[EMAIL PROTECTED]> wrote:
>
>> Now, if we can't meet somewhere in o.a.c.l, I am
>> happy to do an interface
>> package o.a.c.gl, which I hope wouldn't be -1'd when
>> proposed to commons
>> proper because of the existance of o.a.c.l...
>>
>> geir
>>
>
> Now, if we can't meet somewhere in o.a.c.l, I am
> happy to do an interface
> package o.a.c.gl, which I hope wouldn't be -1'd when
> proposed to commons
> proper because of the existance of o.a.c.l...
>
> geir
>
I'm -0 on a backwards-compatible change that does not
affect performance. I am
To: Jakarta Commons Developers
List
.org>cc:
On 4/5/02 11:57 AM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
>>
>> Yes, I have a LogFactory as well - same interface as o.a.c.l -
>> implementation free - the o.a.c.gl package contains no impl of anything so
>> you can have the gl.
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
> Yes, I have a LogFactory as well - same interface as o.a.c.l -
> implementation free - the o.a.c.gl package contains no impl of anything so
> you can have the gl.jar in your classpath and all is well if you do your own
> impl...
>
Java doesn't
On 4/5/02 11:25 AM, "Christoph Reck" <[EMAIL PROTECTED]> wrote:
> Geir, could you agree in having the o.a.c.l build file pop out an
> logifc.jar with what you want instead of creating another o.a.c.gl
> package with practically the same interfaces as in o.a.c.l ?
I'm the one groveling for change
Geir, could you agree in having the o.a.c.l build file pop out an
logifc.jar with what you want instead of creating another o.a.c.gl
package with practically the same interfaces as in o.a.c.l ?
Just my 0.02c: If you look at the commons(-sandbox) its hard to
identify what you need - "you don't se
On 4/5/02 10:17 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
o.a.c.genericlog.Log
o.a.c.genericlog.LogUser
o.a.c.genericlog.LogFactory
>>>
>>> You already have 2 of them ( Log and LogFactory).
>>
>> In o.a.c.l with so
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
> >> o.a.c.genericlog.Log
> >> o.a.c.genericlog.LogUser
> >> o.a.c.genericlog.LogFactory
> >
> > You already have 2 of them ( Log and LogFactory).
>
> In o.a.c.l with some implicit assumptions (which I am trying to dodge...)
It's quite explic
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
> All I want is a base 'commons component' with two interfaces (ok maybe more
> than two - three)
>
> o.a.c.genericlog.Log
> o.a.c.genericlog.LogUser
> o.a.c.genericlog.LogFactory
You already have 2 of them ( Log and LogFactory). The question
+1 provided the interface method does not preclude using the regular
method. The interface method is not appropriate for all circumstances.
Geir Magnusson Jr. wrote:
>On 4/5/02 9:07 AM, "Richard Sitze" <[EMAIL PROTECTED]> wrote:
>
>>Well... yes... I was "rearranging the deck chairs".I mov
From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
> What I propose is a separate package - so that you include the o.a.c.gl
jar
> when you just want the interfaces, and both (or just o.a.c.l) when you
want
> the actual impl.
>
> Remember, I am coming from the POV that I already have logging (which
c
On 4/5/02 9:07 AM, "Richard Sitze" <[EMAIL PROTECTED]> wrote:
> Well... yes... I was "rearranging the deck chairs".I move all
> implementation out of the one package, and into another (btw, LogFactory is
> an abstract class with some code specified, it's not an interfact).
>
> How is that si
.net>cc:
Subject: Re: [logging] Need
interface... VOTE
04/05/2002 04:45
On 4/4/02 5:15 PM, "Richard Sitze" <[EMAIL PROTECTED]> wrote:
> OK then, let's see what happens:
>
> I PROPOSE that the classes in commons logging be rearranged as follows:
>
> no change:
> org.apache.commons.logging.Log
> org.apache.commons.logging.impl.Jdk14Loger.java
> org.apache.commons.
t: Re: [logging] Need interface... VOTE
> Importance: High
>
>
> OK then, let's see what happens:
>
> I PROPOSE that the classes in commons logging be rearranged as follows:
>
> no change:
>org.apache.commons.logging.Log
>
-1.
The registration/discovery mechansims are essential for Logging
functionality.
Not to mention backward compatibility.
Costin
On Thu, 4 Apr 2002, Richard Sitze wrote:
> OK then, let's see what happens:
>
> I PROPOSE that the classes in commons logging be rearranged as follows:
>
> no
OK then, let's see what happens:
I PROPOSE that the classes in commons logging be rearranged as follows:
no change:
org.apache.commons.logging.Log
org.apache.commons.logging.impl.Jdk14Loger.java
org.apache.commons.logging.impl.Log4JCategoryLog.java
org.apache.commons.logging.impl.Log
40 matches
Mail list logo
