On 24 Jul, 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.
Yes, and thats JMSProviderAdapter. When I wrote the ra I was the first
one ever to use the connector spec for JMS (as far as I know), and
therefore my ambition was to use it protable between servers. To adapt a
new JMS provider, a provider specific JMSProviderAdapter had to be
written.
Today it rather more looks as if every JMS provider in the future will
provide its own ra (because XA integration will go throught that once
the connector spec 2.0 is out).
Which basically means that the ra probably should have been placed in
jbossmq in the first place, and could have been more tightly integrated
into it.
>
> 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.
Nor do I.
>
>> >> 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.
Ok, I give up ;-).
Thats OK for me (and as I said above, thinking about it JMS ra's will
probably be JMS provider specific in the future).
//Peter
>
> 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
--
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems Architect WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
