There isn't anything special you have to do inside JBoss to read and write files, although I'm not sure why you would need Java Enterprise / JBoss to read and write files. That can be done in plain old Java.
Additional to say is that reading/writing files from JavaEE applications is against the JavaEE specification. It will work, but you might have issues if you migrate the applicaiton between different vendors or AS versions.
I'm not sure whether you use the appropriate architecture
Exactly wfink. Same goes for sockets. I currently work on a system where there are several socket-based protocols that the system needs to use. Each of those has a POJO JVM adapter process that handles those socket communications and translates them into Java Enterprise things (JMS messages and / or remote EJB calls) for processing in the JBoss cluster. All the database and web stuff is done in the JBoss cluster.
Another option is to use a JCA adapter which might be easier to handle as a separate JVM process.
Never done that but there are several examples how to do it with IronJacamar
Ah, like JDBC. I could see that working for a pool of client sockets. In my case, there are server sockets as well as non-poolable stateful client sockets (the state lasts all day, or maybe many days). Would JCA be a fit for that?
Appreciating your comments. I think my query was not clear.
Actually, there are multiple adapter are written to process the file stream.
Invoking the Adapter/Parser.
Monitor the running adapter/parser.
if new files arrive in poller directory, Jboss invokes the related parser/adapter automatically to process the files.
monitor the Logs of all parser/adapter.
If any issue found in the Adapter/Parser Log, trigger the mail/sms services. etc.
I am confused If Adapter/parser is not in the same JVM how Jboss will monitor.
So I need to know How to write application which will reside in the same JVM.
As already said before by Wolf-Dieter Fink, any blocking I/O inside container managed stuff like EJBs is not allowed, although it generally works. But the AS then looses control of threads as they might block on I/O.
When processing inside same JVM is required, I/O should be done by a resource adapter.
I implemented such thing long time ago, adjusting to the new JBoss releases, but you might have a look at https://xadisk.java.net/. This looks really interesting to me and is up to date.
I wish I'd have the time to test a replacement of my implementation with it.
That doesn't sound like a good use of a Java Enterprise container like JBoss. Sounds more like a batch processing / ETL. I do that with Jenkins running ETL scripts written in groovy, some of which ping the app server cluster with HTTP when the data is ready.