Throwing an exception to indicate a failed authentication

This is a multipart message in MIME format.
--=_alternative 002763ED4A256E5A_=
Content-Type: text/plain; charset="US-ASCII"

Hi. We are implementing a J2CA (version1.0) Resource Adapter in order to
provide access to our own EIS. I've got a couple of questions to ask:

Firstly, is it appropriate to throw a javax.resource.spi.SecurityException
from an implementation the
javax.resource.cci.ConnectionFactory.getConnection() method when a
Resource Adapter client has insufficient privileges to access the
underlying EIS?  The description of javax.resource.spi.SecurityException,
in section 12.2 J2CA spec v1.0, seems to indicate that this is an
appropriate exception for these circumstances. However, the fact that this
exception belongs to an "SPI" package makes me wonder whether it is
appropriate to throw this exception out through the "CCI".


Secondly, we are choosing to throw this SecurityException out of our
implementation of
javax.resource.spi.ManagedConnectionFactory.createManagedConnection() when
it has been detected that authentication with the EIS has failed. We are
expecting that this exception will be propagated to the client of the
Resource Adapter. However, this is beyond our control because the
application server intervenes.
ManagedConnectionFactory.createManagedConnection() is actually being
called by the implementation of javax.resource.spi.ConnectionManager that
is provided by IBM's Websphere Application Server (WAS). WAS chooses to
catch this SecurityException and throw (instead) a
javax.resource.spi.ResourceAllocationException.  So, our
ConnectionFactory.getConnection() has asked WAS's ConnectionManager to
allocate a connection, and this ConnectionManager has thrown a
ResourceAllocationException.

In my mind, there seems to be a bit of a gap in the J2CA spec. The spec
does not prescribe what sort of exception should be thrown from
ConnectionFactory.getConnection() in these circumstances. So, we cannot
tell our clients what sort of exception to expect for a failed
authentication, and we are at the mercy of the application servers
implementation as to exactly which exception will be thrown.

Is my summation correct? Or am I missing something. Would anyone care to
comment?

Thanks very much,
Stephen New


--
This transmission is for the intended addressee only and is confidential information. If you have received this transmission in error, please notify the sender and delete the transmission. The contents of this e-mail are the opinion of the writer only and are not endorsed by the Mincom Group of companies unless expressly stated otherwise.


===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff CONNECTOR-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".

--=_alternative 002763ED4A256E5A_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Hi. We are implementing a J2CA (version1.0)
Resource Adapter in order to provide access to our own EIS. I've got a
couple of questions to ask:</font>
<br>
<br><font size=2 face="sans-serif">Firstly, is it appropriate to throw
a javax.resource.spi.SecurityException from an implementation the javax.resource.cci.ConnectionFactory.getConnection()
method when a Resource Adapter client has insufficient privileges to access
the underlying EIS? &nbsp;The description of javax.resource.spi.SecurityException,
in section 12.2 J2CA spec v1.0, seems to indicate that this is an appropriate
exception for these circumstances. However, the fact that this exception
belongs to an &quot;SPI&quot; package makes me wonder whether it is appropriate
to throw this exception out through the &quot;CCI&quot;.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Secondly, we are choosing to throw this
SecurityException out of our implementation of javax.resource.spi.ManagedConnectionFactory.createManagedConnection()
when it has been detected that authentication with the EIS has failed.
We are expecting that this exception will be propagated to the client of
the Resource Adapter. However, this is beyond our control because the application
server intervenes. &nbsp;ManagedConnectionFactory.createManagedConnection()
is actually being called by the implementation of javax.resource.spi.ConnectionManager
that is provided by IBM's Websphere Application Server (WAS). WAS chooses
to catch this SecurityException and throw (instead) a javax.resource.spi.ResourceAllocationException.
&nbsp;So, our ConnectionFactory.getConnection() has asked WAS's ConnectionManager
to allocate a connection, and this ConnectionManager has thrown a ResourceAllocationException.</font>
<br>
<br><font size=2 face="sans-serif">In my mind, there seems to be a bit
of a gap in the J2CA spec. The spec does not prescribe what sort of exception
should be thrown from ConnectionFactory.getConnection() in these circumstances.
So, we cannot tell our clients what sort of exception to expect for a failed
authentication, and we are at the mercy of the application servers implementation
as to exactly which exception will be thrown.</font>
<br>
<br><font size=2 face="sans-serif">Is my summation correct? Or am I missing
something. Would anyone care to comment?</font>
<br>
<br><font size=2 face="sans-serif">Thanks very much,</font>
<br><font size=2 face="Arial"><b>Stephen New <br>
</b></font><FONT SIZE=3><BR>
<BR>
-- <BR>
This transmission is for the intended addressee only and is confidential information. If you have received this transmission in error, please notify the sender and delete the transmission. The contents of this e-mail are the opinion of the writer only and are not endorsed by the Mincom Group of companies unless expressly stated otherwise.<BR>
</FONT>
===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff CONNECTOR-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".

--=_alternative 002763ED4A256E5A_=--