I want to make some file operations (copy) in stateless EJB Method. I know about not recommndig to do it. But it could be possible for some special EJB implementation. What is the best thing for Wildfly ?
EDIT Some disturbing old links:
"Sun blueprint: EJB Restrictions"
What is the best thing for Wildfly ?
Just doing the file operation (seriously). It's not as-if there's a security manager installed to prevent you from doing this.
And a stateless EJB is not different from many other types of methods in beans in Java EE. It's not the case, as some people think, that it's not allowed in EJB methods but is allowed in CDI bean methods. This is simply not the case.
There's some old information out there, where the spec said that "EJB was not allowed to". But what was actually meant is that Java EE was not allowed to. At the time EJB was seen as equivalent to Java EE, so that's the origin of this wide spread confusion.
Later this myth was starting a life of its own where people dreamed up scenarios where it was supposedly allowed to do IO in Servlets, but not from an EJB, so they designed all kinds of crazy architectures to delegate IO (or threading, another favorite) from an EJB to a Servlet. Absolutely ludicrous!
The restriction (as mentioned above, intended for the whole of Java EE, not just EJB) was also put in too eagerly. There's simply no reason to absolutely forbid it.
Some of the answers that you quote are more retroactive reasons. People just make up reasons for a rule to somehow justify their world, even though the reason and the rule don't match.
For this reason, the rule has been removed from the EJB spec.
That's right, in the current EJB spec you will not longer find that it's forbidden to use IO from an EJB (which, again, never meant to say "EJB", but should be read as "Java EE").
See:
Of course, as with many things, you may or may not have to be cautious when using IO, but this is completely unrelated to Java EE or EJB and holds for almost any application, and is more dependent on the kind of IO, the kind of application you're coding and your situation.
Two small extreme examples:
Your very own personal Java EE application of which you are the only developer that you installed at home on your raspberry pi and that reads a small configuration file at startup from an external location -> pretty much always okay.
Large clustered enterprise application being developed by many different teams, integrated separately, deployed separately, highly transactional that wants to write temporary data to a filesystem but that has to be cleanedup again when the transaction ends -> likely not such a good idea.
Between those two that are literally an infinite amount of variations. We had for example a larger enterprise application that did IO to an external folder from a Singleton in a very controlled and specific way. The app served millions of users under intense load and there was never a problem with the IO. So even "enterprise" and "transactional" do not necessarily have to mean "no IO". It really depends.