Discussions

Web tier: servlets, JSP, Web frameworks: How application running on remote machine will accesss files on

  1. I am deploying my application in oc4j. i am generating xml files and posted it to my local drive. another listener thread which is running on remote machine will trigured the process when new xml file is posted in a folder. how it will do this with out using FTP protocol. how to find a common share location between Application server environment and remote machine Interface where listner is running.
  2. You can use a URLConnection to stream a file to and from a file share. Use of java.io is prohibited by the EJB spec.

    However I must ask why you are writing XML to a file that is to be detected by a listener? If your objective is to send an XML message to a remote server, there are better ways to do this than via file shares. For example, you should use JMS or RMI.
  3. You can use a URLConnection to stream a file to and from a file share. Use of java.io is prohibited by the EJB spec.

    Can you post some details on this? I have an application which on the backend (a scheduler will periodically call an EJB session bean) will need to create a text file and then FTP them to another system (legacy systems -- gotta love 'em). I've been busy with other parts of the application, so I haven't really had time to research this, but it is a critical part of my application.
  4. Some digging on this reveals the following information:

    "...enterprise beans should not... create, modify, or delete files on the filesystem" Then the reader is directed to "see § 18.1.2 of the EJB 1.1 specification."

    This is at http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/ejb_tier/qanda/restrictions.html.

    I am unsure if this still applies in the EJB 2.1 spec, but I have a feeling it does.

    I don't know what I'm going to do about my project... anybody else out there faced this one?
  5. I keep replying to myself...

    It is present in some sense in the 2.1 spec as well:

    "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." (§ 25.1.2)

    Hmm....
  6. Hi Aaron - yes it does apply to EJB 2.1. From the resource you reference:
    Enterprise beans aren't allowed to access files primarily because files are not transactional resources. Allowing EJBs to access files or directories in the filesystem, or to use file descriptors, would compromise component distributability, and would be a security hazard.

    Another reason is deployability.

    This is a better explanation of the reason why. You can see how a URL is slightly less bound to a particular network than filename.

    However, I understand the most appropriate solution is to use a custom-built JCA connector to access file systems from EJBs.
  7. ...I understand the most appropriate solution is to use a custom-built JCA connector to access file systems from EJBs.

    Can you point me towards any resources that explain how to do this (particularly create a JCA connector -- I think I can figure out the file I/O itself)?
  8. This won't help the original poster, and I'm still interested in learning about the JCA solution posed. However, I believe I have found a workaround for my project. Since my requirement is effectively to create a file for sending to another system, there is no real need for me to actually create it locally. Instead, I realized that if I could actually use an FTP connection programmatically, I could effectively generate the file directly to the remote server.

    Enter Jakarta Commons Net (1.3.0). Particularly, org.apache.commons.net.ftp.FTPClient.storeFileStream(). Using this, I can retrieve an OutputStream and call write() as needed to create the file.

    This skirts the line drawn by the EJB spec, since I am using java.io classes to do file I/O. However, the spec says that it must not "...attempt to access files and directories in the file system." I interpret this as being the local file system of the application server -- not a remote file system. In addition, I don't think this violates the spirit of the rule, as the FTP file system is meant to be exposed, and is in a known location that is operating system independent.

    Using this, one might also be able to "fake" file I/O on the app-server itself -- all you would need to do would be install an FTP server. However, this may not be the most appropriate solution, as anyone who could gain a connection to the FTP server could attempt to log in and access the files. In addition, bi-directional I/O (i.e. read/write, random access, etc.) would not be directly possible using this method.