I say keep it simple and working with jboss- use log4j directly. If
someone wants to use it elsewhere we can deal with that later. After all,
the spec doesn't specify that anything in particular needs to be logged,
does it?
presumably we could bundle log4j into the jar if someone wanted to deploy
it in a log4j free environment.
david jencks
On 2001.07.24 14:36:35 -0400 Jason Dillon wrote:
> On Tue, 24 Jul 2001, Peter Antman wrote:
>
> > On 24 Jul, Jason Dillon wrote:
> > >> Well, that depends on taste. When the JMS RA was written it was mean
> to
> > >> not be dependant on JBoss at all, but should be possible to use in
> any
> > >> App server. There was one (easy to fix dependancy then). Changes
> done
> > >> since then has tied it more closely to JBoss. I guess it would
> therefore
> > >> be ok to integrate it even more tightly.
> > >
> > > What changes make it JBoss specific?
> >
> > Today there are two dependencys of jboss outside the ra package:
> >
> > import org.jboss.jms.ConnectionFactoryHelper;
> > import org.jboss.jms.jndi.JMSProviderAdapter;
>
> ConnectionFactoryHelper is not JBoss specific, so it could be used in
> another server. It is support for the resource adapter and is not
> exposed, so I do not think there is a portiblity problem there. Come to
> think of it JMSProviderAdapter is not either, but I doubt that JMS
> vendors
> would implement it. There would have to an interface adapter provided by
> the JMS vendor to work with the JBoss RA.
>
> Is there any spec compliant way to replace JMSProviderAdapter?
>
> > >> It is, however, questionable, if we then should really call it a
> J2EE
> > >> connector resource adapter any more, because if its not spec
> compliant
> > >> (i.e, working in any app server) it is no longer a J2EE connector
> > >> resource adapter.
> > >
> > > What is the spec sucks when it comes to logging?
> >
> > Well, I guess you either skipp the spec or try to influence it to
> change
> > to the better.
>
> I personaly do not have lots of time to try and influence Sun/JSR/Whoever
> that there API is lacking. I wish I did, but right now I do not.
>
> > >> Since J2EE Connector 2.0 will include support for asynchrounous
> calls
> > >> and the JMS spec and the connector spec will probably by integrating
> the
> > >> transactional stuff for JMS through the connector spec, I think It
> is
> > >> good to keep the JMS connector clean.
> > >
> > > Me too, but I can't handle a PrintWriter for a log destination =(
> >
> > There are a couple of ways to do it:
> >
> > 1. You could perhaps say that a particular resource adapter uses log4j,
> > and that that is part of the contract (actually I then think that
> the
> > log4j lib should be part of the *.rar archive. I.e, one may base the
> > logging in the adapter on loh4j.
> >
> > 2. This logging must also be made available to the PrintWriter (i.e, if
> > the app server sets a prinwriter, the log4j has to log its output to
> > that.
> >
> > 3. This means that it is up to the impl of the app server Connector
> part
> > if it should really use the PrintWriter API to get logging from an
> > adapter. It is then up to that to integrate the logging into JBoss.
> >
> > 4. A possible scenario (I guess) would be to introduce a JBoss specific
> > API into the the contract between a JBoss aware adapter and the
> JBoss
> > connector impl, so that it may check if the adapter support JBoss
> > specific logging stuff.
>
> Is it worth all this? Do we expect to publish the ra seperate from the
> server? If so are we going to support it in other servers? I think that
> the API is good to allow other vendors to provide adapters which can plug
> into the server, but I think that we can "bend" the rules of the spec a
> little when it comes to the internal operations of the adapter which is
> meant to be used inside of JBoss.
>
> So, I would not suggest breaking and external api, such as throwing
> unexpected exceptions or returning nulls where a null is not expected,
> but
> internally the only reason to not use Log4j for logging instead of a
> PrintWriter is so that the adapter could be plugged into a different app
> server that did not use Log4j and expected logging to be done from the
> PrintWriter.
>
> If that is the case, then lets pass a CategoryStream wraped up to look
> like
> a PrintWriter to the RA when we load it and set all logging to DEBUG. If
> not, lets forget about the PrintWriter and using a Category directly and
> make use of DEBUG and other priorities.
>
> Perhaps in the future (once 1.4 is release) the spec will use the new
> logging api, which we could then adapt to 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
