Re: Throwing an exception to indicate a failed authentication
New Stephen <[email protected]> Thu, 18 Mar 2004 15:56:47 +1000
| Newsgroups | gmane.comp.java.sun.connector |
|---|---|
| Message-ID | <OFD873DC20.52266FDA-ON4A256E5B.001FBC67-4A256E5B.0020AA52@mincom.com> |
This is a multipart message in MIME format. --=_alternative 0020AA4B4A256E5B_= Content-Type: text/plain; charset="US-ASCII" Thanks, Kevin, for your answer. It's just a bit disappointing because it means that J2CA RA clients will have to be coded differently, depending on which application server the the J2CA RA is deployed into. And because the type of exception is not contracted in the specification, it means that if the appserver vendor changes their mind about what sort of exception to throw (in some future version of the appserver) then our code will have to change also. Hopefully this sort of change would be well-documented by appserver vendors so that it does not escape our attention. Thanks! Stephen New Kevin Sutter <[email protected]> Sent by: "A public list for J2EE Connector architecture interest." <[email protected]> 18/03/04 12:50 AM Please respond to "A public list for J2EE Connector architecture interest." <[email protected]> To [email protected] cc Subject Re: Throwing an exception to indicate a failed authentication Section 19.2 of the J2EE Connector Architecture version 1.5 document is fairly clear on which exception should be expected in the various scenarios described below. As with any spec, there is always wiggle room for interpretation. But, in the case of the SecurityException, the spec is pretty clear that this is used between the Application Server and the Resource Adapter (not between the client application and the app server or resource adapter): javax.resource.spi.SecurityException: ASecurityException indicates error conditions related to the security contract between an application server and resource adapter... And, the ResourceAllocationException can be thrown by either the Application Server or the Resource Adapter: javax.resource.spi.ResourceAllocationException: This exception is thrown by an application server or resource adapter to indicate a failure to allocate system resources, such as threads and physical connections... Since the signature for the getConnection() method only has the parent javax.resource.ResourceException, that's the only requirement. And, the only exception that you can definitely count on across application servers. As shown above, the spec outlines expectations for other exceptions, but since the "contract" on getConnection isn't specific enough, you can't count on it. ----------------------------------------------------------- Kevin Sutter, WebSphere Distributed (J2EE Connectors) mail: [email protected], Kevin Sutter/Rochester/IBM New Stephen <Stephen.New@MINC OM.COM> To Sent by: "A [email protected] public list for cc J2EE Connector architecture Subject interest." Throwing an exception to indicate a <CONNECTOR-INTERE failed authentication [email protected]> 03/17/2004 01:10 AM Please respond to "A public list for J2EE Connector architecture interest." 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". =========================================================================== 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". -- 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 0020AA4B4A256E5B_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Thanks, Kevin, for your answer.</font> <br> <br><font size=2 face="sans-serif">It's just a bit disappointing because it means that J2CA RA clients will have to be coded differently, depending on which application server the the J2CA RA is deployed into. And because the type of exception is not contracted in the specification, it means that if the appserver vendor changes their mind about what sort of exception to throw (in some future version of the appserver) then our code will have to change also. Hopefully this sort of change would be well-documented by appserver vendors so that it does not escape our attention.</font> <br> <br><font size=2 face="sans-serif">Thanks! </font> <br><font size=2 face="sans-serif"><br> </font><font size=2 face="Arial"><b>Stephen New <br> </b></font> <br> <br> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>Kevin Sutter <[email protected]></b> </font> <br><font size=1 face="sans-serif">Sent by: "A public list for J2EE Connector architecture interest." <[email protected]></font> <p><font size=1 face="sans-serif">18/03/04 12:50 AM</font> <table border> <tr valign=top> <td bgcolor=white> <div align=center><font size=1 face="sans-serif">Please respond to<br> "A public list for J2EE Connector architecture interest." <[email protected]></font></div></table> <br> <td width=59%> <table width=100%> <tr> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td valign=top><font size=1 face="sans-serif">[email protected]</font> <tr> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td valign=top> <tr> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td valign=top><font size=1 face="sans-serif">Re: Throwing an exception to indicate a failed authentication</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><font size=2><tt>Section 19.2 of the J2EE Connector Architecture version 1.5 document is<br> fairly clear on which exception should be expected in the various scenarios<br> described below. As with any spec, there is always wiggle room for<br> interpretation. But, in the case of the SecurityException, the spec is<br> pretty clear that this is used between the Application Server and the<br> Resource Adapter (not between the client application and the app server or<br> resource adapter):<br> <br> javax.resource.spi.SecurityException: ASecurityException indicates<br> error conditions related to the security contract between an application<br> server and<br> resource adapter...<br> <br> And, the ResourceAllocationException can be thrown by either the<br> Application Server or the Resource Adapter:<br> <br> javax.resource.spi.ResourceAllocationException: This exception is<br> thrown by an application server or resource adapter to indicate a<br> failure to<br> allocate system resources, such as threads and physical connections...<br> <br> Since the signature for the getConnection() method only has the parent<br> javax.resource.ResourceException, that's the only requirement. And, the<br> only exception that you can definitely count on across application servers.<br> As shown above, the spec outlines expectations for other exceptions, but<br> since the "contract" on getConnection isn't specific enough, you can't<br> count on it.<br> <br> -----------------------------------------------------------<br> Kevin Sutter, WebSphere Distributed (J2EE Connectors)<br> mail: [email protected], Kevin Sutter/Rochester/IBM<br> <br> <br> <br> <br> New Stephen<br> <Stephen.New@MINC<br> OM.COM> To<br> Sent by: "A [email protected]<br> public list for cc<br> J2EE Connector<br> architecture Subject<br> interest." Throwing an exception to indicate a<br> <CONNECTOR-INTERE failed authentication<br> [email protected]><br> <br> <br> 03/17/2004 01:10<br> AM<br> <br> <br> Please respond to<br> "A public list<br> for J2EE<br> Connector<br> architecture<br> interest."<br> <br> <br> <br> <br> <br> <br> <br> Hi. We are implementing a J2CA (version1.0) Resource Adapter in order to<br> provide access to our own EIS. I've got a couple of questions to ask:<br> <br> Firstly, is it appropriate to throw a javax.resource.spi.SecurityException<br> from an implementation the<br> javax.resource.cci.ConnectionFactory.getConnection() method when a Resource<br> Adapter client has insufficient privileges to access the underlying EIS?<br> The description of javax.resource.spi.SecurityException, in section 12.2<br> J2CA spec v1.0, seems to indicate that this is an appropriate exception for<br> these circumstances. However, the fact that this exception belongs to an<br> "SPI" package makes me wonder whether it is appropriate to throw this<br> exception out through the "CCI".<br> <br> <br> Secondly, we are choosing to throw this SecurityException out of our<br> implementation of<br> javax.resource.spi.ManagedConnectionFactory.createManagedConnection() when<br> it has been detected that authentication with the EIS has failed. We are<br> expecting that this exception will be propagated to the client of the<br> Resource Adapter. However, this is beyond our control because the<br> application server intervenes.<br> ManagedConnectionFactory.createManagedConnection() is actually being called<br> by the implementation of javax.resource.spi.ConnectionManager that is<br> provided by IBM's Websphere Application Server (WAS). WAS chooses to catch<br> this SecurityException and throw (instead) a<br> javax.resource.spi.ResourceAllocationException. So, our<br> ConnectionFactory.getConnection() has asked WAS's ConnectionManager to<br> allocate a connection, and this ConnectionManager has thrown a<br> ResourceAllocationException.<br> <br> In my mind, there seems to be a bit of a gap in the J2CA spec. The spec<br> does not prescribe what sort of exception should be thrown from<br> ConnectionFactory.getConnection() in these circumstances. So, we cannot<br> tell our clients what sort of exception to expect for a failed<br> authentication, and we are at the mercy of the application servers<br> implementation as to exactly which exception will be thrown.<br> <br> Is my summation correct? Or am I missing something. Would anyone care to<br> comment?<br> <br> Thanks very much,<br> Stephen New<br> <br> <br> --<br> This transmission is for the intended addressee only and is confidential<br> information. If you have received this transmission in error, please notify<br> the sender and delete the transmission. The contents of this e-mail are the<br> opinion of the writer only and are not endorsed by the Mincom Group of<br> companies unless expressly stated otherwise.<br> ===========================================================================<br> To unsubscribe, send email to [email protected] and include in the body<br> of the message "signoff CONNECTOR-INTEREST". For general help, send email<br> to [email protected] and include in the body of the message "help".<br> <br> ===========================================================================<br> To unsubscribe, send email to [email protected] and include in the body<br> of the message "signoff CONNECTOR-INTEREST". For general help, send email to<br> [email protected] and include in the body of the message "help".<br> </tt></font> <br><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 0020AA4B4A256E5B_=--