Kevin Gaasch wrote: > > By posting your question to this list, we are assuming that you are > interesting in our interpretation of the specification. It is obvious > that you can read the language of the specification as well as any of > us. So, the only added information that we can provide to you is how we > believe the specification should be interpreted. So far, here is what I > have gathered from YOUR postings to this list: > > 1. You have already examined the specification and formulated your own > 'by the letter' interpretation (which is great, that's what it is for). > 2. Any postings that provide a 'beyond the letter' interpretation, you > reject because you are not interested in anything outside the scope of > the black-n-white text.
No. My posting was intended to gather opinions as to whether "native library" equals "JNI". Or even to gather information from some other standard that either made it clear that JNI was allowed or that JNI was not allowed. > 3. The only posting that seems to be acceptable is "Yes, you have read > the specification correctly. JNI is not disallowed." > Nope. If you have a source, either another standard or something similar which says that "native library" equals "JNI" then feel free to post. However, no one posted anything like that. And, from the posts I saw, the vast majority seemed to take the stance that it was ok but it "just wasn't a good idea." Which I don't disagree with. There are dangers. But there is a great deal of difference between that and the stance that it should never ever be done that way. Of course if someone is going to make a statement that it should never be done that way then I would expect them to back it up with some reasonable explaination. Either from a source or a generalization from their own experience. There were some responses like that but they were either focusing on because there might be a better way or because it isn't "portable." The latter is redundant since JNI by its nature is not portable. And the former doesn't address the main issue in clear terms. And I am not saying that neither argument is without merit, but rather that neither clearly leads to disallowing JNI in an EJB. > Therefore, any more posting on this thread will add no value to your > original question. Now, if anyone is interested in discussing the > 'hidden meaning' of the specification with regard to JNI from EJB, then > please continue the discussion. Otherwise, could we please close this > thread. > > Kevin E. Gaasch =========================================================================== 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".
