Multithreading to allow multiple clients on to a server and client requests handling
Note: 
It is easier to provide a more complete answer when faced with a complete problem. There are several //other code areas that you may be omitting for the sake of brevity, but these could very well be providing more context to the review, and their presence could likely improve the quality of answers received. 

I would recommend posting complete code as is, using a more descriptive place holder of the logic there than //other code and/or perhaps an explanation of why the missing code is considered irrelevant to the reviewer

/rant



Request for clarification
I noticed that in your AcceptingClients Thread you make a call to new ClientRequests(socket, inputStream, outputStream). However, you also define the similarly named ClientRequest with constructor public ClientRequest(Socket socket). Are these meant to be the same class, just with the latter being un-implemented? or are these differing classes, in which case I would recommend better names

On to your questions 3:


  1) Is it good to put all those thread in one class


Having a class ServerOperations containing each of your Operation threads IMO is actually good design (so long as each operation is reasonably simple). 

When it comes to denser and thus more complex logic, I would instead opt for grouping each Operation class into a subdirectory /operations and using ServerOperations like a repository; a layer for accessing your collection of operations, something like ServerOperations.getOperationThread("acceptClients").

The benefit here is readability and maintainability. IMHO It is easier to understand and thus maintain the individual processes if they are in separate class files, but this would only be recommended for a collection of non-trivial Operations. If they are super simple, feel free to group them up like this!  


  Using this way may give me problems if I have a lot of clients connected?


Short answer, yes. Based on the present code, I would highly recommend using non-daemon threads for these purposes. This question on SO has a TON of discourse on daemon threads but IMO the most relevant information therein is :


  Daemon threads are service providers for user threads running in the same process.


This means any Thread with setDaemon(true) should be considered a service, something that is running in the background and waiting to service a request from another, non-daemon thread. This leads the most annoying impact:


  Daemon threads can shut down any time in between their flow, Non-Daemon i.e. user thread executes completely.


Normally, if your program were ending, it would hang on exiting the JVM until all user threads are complete. As these threads are daemons, the JVM will drop these Threads and exit immediately. This means that in the edge case of a request still processing on shutdown, you will lose requests processing in these daemons.

Without information on how this daemon is used in these //other code sections, I can only conclude that you might not need to use daemonThreads




  2) If i don't extend the class AcceptingClients with Thread I have problem with JavaFX UI thread


I am unfamiliar with JavaFX so I won't offer advice I am unqualified to give




  3) To let everything run I have a method in my model where this method serverConnection() is called. [..] Good or not?!


If I am understanding this correctly, you are asking if it is good to call this method from the Model at creation (IMO that isn't a bad choice in the general sense). This question is incredibly difficult to answer without having the Model code available for context. 

IMHO, this last is a question belonging in a review of the Model, or of the project as a whole, as without seeing the complete context of HOW this method is used, any feedback would basically be personal opinions about the proper use of MVC models

Hope some if not all of this helps!