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
