Should I put the Services and Domain Layer into seperate jar file and include it into my web application (like any other jar file)? These layers will use hibernate. I think my idea project is getting too large with all the layers, but it's nice having it all there at the same time. What do you experts do?

For a JBoss app I have been building, I have the persistence domain in a sar file and the EJB and DAOs in its own jar. During development it works well in terms of hot deployment. In a production or QA senario then they will be packaged into a single ear which gives you the best of both worlds.

I guess that makes test suites fairly manageable too, right? I mean, I know you can compose them in a modular manner, but I hate looking at a project with over 300 classes, no matter how well they are organized with respect to packages and all that.

I was thinking of putting all my domain layer and a services layer (facade) into it's own package. The facade would probably have a superclass with hibernate in it to make it easy for specify services to extend it without worrying about the specifics of persistance too much (just nice 1 or 3-line calls depending on what you are doing). Basically I would call this 'appname-business.jar' or something like that. Then, I would include that jar file into the web application and have webwork actions call the services.

Do you think I'll have problems configuring hibernate inside the application server even though I'm building a jar file with the hibernate calls that is designed without the use of one?

All the app server will be looking for will be the mapping files and mapped domain classes. There is no issue here, as far as the appserver is concerned, having the services in there aswell. Also, it does make test suite easier as you can build and run tests, optionally, outside of the appserver.