I think there is one... CategoryStream, which you would have to wrap with a
PrintWriter... but that should do the job.

I would recommend that you use it for the getLogger() methods.

--jason


On Fri, 17 Aug 2001, David Jencks wrote:

> I'm fixing the logging in all the code that's ours.  Its just going to use
> log4j and ignore any interface-mandated SetPrintWriter type methods.
>
> For other peoples resource adapters, I would like to supply them with a
> printwriter that writes to a Category.info that we supply.  I haven't
> looked into how to do this yet, if it's obvious to someone please let me
> know.
>
> david jencks
>
> On 2001.08.17 15:27:13 -0400 Jason Dillon wrote:
> > We could write a ResourceLogger, which would extend Category (or
> > JBossCategory), but also implement the setLogger|getLogger crap.  By
> > default
> > it would not have a PrintWriter and would use the category.  If there was
> > a
> > PrintWriter then it would use the category then, println to the
> > PrintWriter.
> >
> > Or if we are not concerend with ever using a custom PrintWriter via
> > setLogger, we could return a CategoryPrintStream (or whatever that class
> > is
> > called) from getLogger(), which would simply wrap the Category which the
> > resource is using.
> >
> > --jason
> >
> >
> > On Thu, 16 Aug 2001, Scott M Stark wrote:
> >
> > > Well, the current level of logging coming from the datasource layer is
> > > absurd. If this is
> > > due to PrintWriter interface screw the spec. Unless someone has called
> > > setLogger the
> > > JBoss RAs should be defaulting to log4j.
> > >
> > > ----- Original Message -----
> > > From: "Jason Dillon" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Thursday, August 16, 2001 6:16 PM
> > > Subject: [JBoss-dev] resource logging
> > >
> > >
> > > > What are we going todo about logging from resource adapters and such?
> >  It
> > > > looks like there is alot of stuff that:
> > > >
> > > >  if (logger != null) {
> > > >     // some use full message
> > > >  }
> > > >
> > > > Or it will not log anything at all... even error conditions.  It also
> > > looks
> > > > like there is alot of System.<out|err> usage too, which just plain
> > sucks.
> > > >
> > > > There was some email with Peter a while ago on the jms ra and
> > logging,
> > > which
> > > > we concluded that we should log4j and more or less ignore the
> > > > javax.resource.* PrintWriter logging crap.
> > > >
> > > > I have not done anything about that yet, since I have been on this
> > bug
> > > > hunt, which lead me to find even more cases like this.
> > > >
> > > > The issues as I see them are:
> > > >
> > > >  1) The current javax.resource.* logging usage of a PrintWriter
> > sucks,
> > > >     really, really, really sucks.
> > > >
> > > >  2) Such a crappy loging mechanism is forcing folks to use adhoc
> > logging
> > > >     semantics, which is making it hard to debug problems when they
> > arise.
> > > >     Worse yet it is "hiding" problems by some code simply not logging
> > > >     anything if it doesn't have a PrintWriter.
> > > >
> > > >  3) Did I mention that PrintWriter for logging sucks... oh ya I
> > did... but
> > > >     it is so bad that I want to list it again.
> > > >
> > > > I am sure there are more issues, but these suffice for the question
> > at
> > > hand,
> > > > which is what are we going to do about this?
> > > >
> > > > I suggest dropping the PrintWriter <get|set>Logger() fluff (replaced
> > by
> > > > empty methods) and implement all logging with Log4j.  I think that
> > this
> > > > is the best bet in the shortterm to get a really stable and
> > functional
> > > > product out there.  It will limit how the ra stuff will plug into
> > other
> > > > servers, but we really want folks to use JBoss, not just canabalize
> > the
> > > > components.
> > > >
> > > > Long term we want to be spec compliant, and perhaps the spec will be
> > > > improvded with respect to logging in the next release.
> > > >
> > > > My conclusion is that being spec compliant and using PrintWriters for
> > > > logging is more harmful than anything else with respect to the rapid
> > > growth,
> > > > stability and feature set of JBoss.
> > > >
> > > > Let us drop it and use Log4j.
> > > >
> > > > --jason
> > > >
> > > >
> > > > _______________________________________________
> > > > Jboss-development mailing list
> > > > [EMAIL PROTECTED]
> > > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > > >
> > >
> > >
> > > _______________________________________________
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>


_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to