On Tue, 7 Nov 2000 14:42:42 -0500, Dave Wolf <[EMAIL PROTECTED]> wrote:
>> Interesting view. Sooo, databases aren't allowed to do file I/O then by
>your
>> reasoning? ;-) Note that there are some databases that run in-VM so
>there's
>> no socket connection between the JDBC driver and the database.
>
>Maybe I mis-understand your position on helper classes Rickard. Remember I
>as a EJB 1.1 developer dont setup JDBC drivers. I simply work at the
>interface layer and a deployer sets the driver. If that deployer on their
>own platform uses a driver that doesnt work on that platform, then that was
>their issue not mine. I worked at the interface layer, stuck with only
>those interfaces which were a part of the spec, and left the specific
driver
>up to the deployer.
>
>For instance, take Jonathans very good point about the Connector
>architecture. Connectectors are interfaces which are part of the EJB spec.
>A deployer maps an interface to an implementation, and should therefore
>choose that implementation based on based on their platform. I see no
issue
>with this, and see no issue if the Connector is a file I/O connector. If
I
>were running on an in-memory file system, as a deployer I would have to
>choose a Connector driver which doesnt use file I/O. But with a helper
>class that YOU developed outside of a predefined interface, the deployer
has
>no choice do they?
But then the issue is not really whether they use file I/O or not. The issue
is then whether or not the library has a "standard" interface or not. Let's
say we simply put a JNDI interface on top of our library that uses file I/O.
By your reasoning it would be ok, and it would be the deployers problem to
make sure it could use a JNDI implementation that worked on the intended
platform.
And this I agree with. I absolutely agree that *as far as possible* the
libraries should use some standard interface as API between it and the
beans. This give you at least some options for migration if necessary.
But, in the cases where *this is not possible* I still think that putting
I/O operations in a separate library which is installed as a "system
library" should be ok.
Then again, as a container provider I can take the easy approach and don't
enforce the restrictions as all, as this would be perfectly spec compliant
(note that the spec says something like "grant these permissions, or more").
It is ok for a container to grant more permissions (i.e. don't care..), but
it is not ok for *bean providers* to rely on more permissions to be
available, at least not if they want to guarantee portability.
/Rickard
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
