The problem is that Class.getResource() returns an URL instance which then does its work through classes of the java.io package. Since the EJB spec does not allow bean providers to play with java.io classes for the sake of portability (EJB spec 24.1.2), it might make sense not to invoke Class.getResource() from your beans.
If you've got something like a properties file that you need to read, one possibility that springs to mind is to include it in your EAR file and use ResourceBundle
Well, I guess that if you have a properties file or something similar the easiest way to go is to use environment entries (EJB spec 20.2) in my opinion. But as soon as you have something more "binarish" to retrieve, the getResourceAsStream() makes sense provided what has been said on the EJB-INTEREST mailing list. You can also store that binary stuff in a database as a BLOB or something which would comply with the programming restrictions.
Besides, the EJB spec is very fuzzy about the usage of java.io classes. It doesn't say much except that... (24.1.2)
...an enterprise bean must not use the java.io package to attempt to access files and directories in the file system. The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data.
This sounds pretty light to me [ June 21, 2004: Message edited by: Valentin Crettaz ]