Nicholas is exactly correct.  The spirit of the restriction is to restrict
file access from within the beans for the purpose of storing/retreiving
"business data".  Business data being, for example, the state of an Entity
EJB.  The reasoning is that filesystems do not support transactional
processing.

However, app server vendors are free to disallow file access at all (and I
think some do).  Thus it is also, somewhat, a portability issue.

That being said, we exclusively use JMS or socket based appenders from
within our EJB deployments.  That has worked great for us.  JMS is slightly
slower, but much more fail-safe.




    |-----Original Message-----
    |From: Nicholas [mailto:[EMAIL PROTECTED]
    |Sent: Tuesday, March 11, 2003 8:31 AM
    |To: Log4J Users List
    |Subject: Re: Do people use log4j in J2EE applications?
    |
    |
    |It is not that black and white. The EJB specification
    |does not prohibit you from writing to a file.
    |
    |EJB Spec 2.0 
    |24.1.2 Programming restrictions
    |.
    |.
    |* 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.
    |
    |//Nicholas
    |
    |
    |
    |--- [EMAIL PROTECTED] wrote:
    |> Hi folks,
    |> 
    |> Just a quick query, as the EJB specification forbids
    |> you to write to a file
    |> (which is what i want to do!)
    |> why is it incorrect to do so?  The alternatives are
    |> using SocketAppender
    |> and JMSApender but how do
    |> you write to a file using these? or put another
    |> way... can you?
    |> 
    |> Cheers,
    |> 
    |>
    |___________________________________________________________
    |____________________
    |>  The information transmitted is intended only for
    |> the person or entity to
    |> which it is addressed and may contain confidential
    |> and/or privileged
    |> material. Statements and opinions expressed in this
    |> e-mail may not
    |> represent those of the company. Any review,
    |> retransmission, dissemination
    |> or other use of, or taking of any action in reliance
    |> upon, this information
    |> by persons or entities other than the intended
    |> recipient is prohibited. If
    |> you received this in error, please contact the
    |> sender immediately and
    |> delete the material from any computer. This e-mail
    |> may be read by an
    |> employee of the company as part of the internal
    |> monitoring process and is
    |> therefore not to be considered private by the sender
    |> or the recipient.
    |> 
    |> 
    |> 
    |>
    |-----------------------------------------------------------
    |----------
    |> To unsubscribe, e-mail:
    |> [EMAIL PROTECTED]
    |> For additional commands, e-mail:
    |> [EMAIL PROTECTED]
    |> 
    |
    |
    |=====
    |Nicholas Whitehead
    |Home: (973) 377 9335
    |Cell: (201) 615 2716
    |[EMAIL PROTECTED]
    |Get Your News From The Crowbar: 
http://crowbar.dnsalias.com:443/crowbar/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to