We Keep Coding

Modular jars/plugins within a Wildfly Web Application using ServiceLoaders

We extensively use Java ServiceLoaders as a plugin infrastructure for our application components. We define interfaces, and then use the loader to load them at run time. Adding additional jars with extensions and service files are fine for our use cases.
However, i'm struggling to understand how we would be able to continue this approach while deploying an application within Wildfly. The intent is as stated above, the ability to add "extension" jars to the web-application class path without having to
Stop the server
Unzip the war
Add additional jar
Zip war
Start the server
In Tomcat, we could deploy web application folders instead of a war. So stopping the server, dropping in a jar, and starting the server worked fine. Within Wildfly (latest), it appears to not like the deployment of a folder vs war.
I've read about the modules approach, but have not been successful using this approach to get the deployed application to see the module from the service loader implementations.
Would like to know if there is an alternative solution or perhaps we are doing something wrong?
Thanks

WildFly supports exploded deployments with the deployment scanner or using the explode command with jboss-cli. Using the jboss-cli you can even update files remotely.

Grails war command: what happens behind the scene

I know that in Grails framework, you can build a war file using
grails war(builds a production war)
or you can build a environment-specific war file using
grails test war
Now, what I am having trouble understanding is, if I build a war file using grails war but deploy it to test environment (where -Dgrails.env=test), the war file built using grails war command runs happily by picking up **test ** environment settings(like pulling data from test urls instead of prod urls).
My question is: what is the point of building a war file using a environment-specific command (ie. why use grails test war when the war file built using grails war works everywhere?).
Am I missing something obvious?

The reason for using an environment is because you may code in your application that hooks into the build process and alters the resulting WAR based on the environment. Such as re configuring some filters in web.xml for instance. It's an extension point. You can use it if you need.

Grails holds three automatic environments: dev, test, prod. there are some
defaults for the various "scripts", e.g. run-app runs dev, test-app runs test,
war build a war for prod. these are there for convenience and make the most
sense from the daily usage patterns for developers. e.g. in testing the
default is an in-mem db.
You can also add more environments, as you see fit. E.g. having an staging
or integration environment is common, so by providing such an env (maybe
only some config or db changes) you can easily build a war file for the server
you use for your QA team.
Another use case is to just build a dev war, as there might be something odd
with the war on the production server and you just need to run the war against
that odd tomcat 6.x real-life environment, but with the dev setting against
your db.
That said, there still is the config you can add via config files, but the
environments give a rather sane setup for "all involved", as they are usually
within version control.
And as a final step you still have access to the environment in your own
scripts/_Events.groovy hooks, where you might e.g. drop or add something,
but that only makes sense for that exact environment (e.g. drop some jars, as
they are on the server already).
At the end, this features gives you some freedom to do what you want. Be glad, if you never have to use it. But once you need, you'll be glad it's there.

java maven how to create app with bundled tomcat

I wonder if this is a somewhat awkward way of thinking, but I couldn't really find any hint on the internet to my idea. Maybe I just did not phrase my question right, but anyhow, this is what I would like to do:
I have a complex application written in java with spring and quartz and a whole load of dependencies. The application is run inside an apache tomcat servlet container. Now I know, I can create a war file and deploy that to the productive server machine (after our internal IT has installed and configured the tomcat on that machine), but I would like to do this a bit different.
I would like maven to create a pre-packaged tomcat application server with all dependencies and configuration settings AND my application. In effect, all that would need to be done on the productive system is, copy the package (or zip or tar.gz or whatever is needed) to the server, unpack it in a directory of my or their choice and fire up this local isolated tomcat. It would only run my application (which poses enough load on the machine anyway) and I could even go so far and deploy a second variant, say for a different customer in the directory next to the first one. Neither of both could interfere with each other, even if they use different versions with different dependencies.
Is it possible to do that? Is it a desirable approach or am I on the completely wrong track here?
What I think would be a benefit of this approach (despite the thing with incompatible dependencies or settings between two or more different installations) is, that I can hand the whole package over to our administration guys and they can simply deploy it to a server without the need to configure anything in the tomcat after installing it and so on.
Any hint???

Create a Maven project as the parent project (type pom). Include your webapp as a module project (type war). Create another module project, maybe "myapp-standalone" (type jar) and include the Embeddable Tomcat as a dependency. Write a starter class to launch the internal Tomcat (see executable jar / überjar). When building the app, copy the created war file into the jar, into Tomcats webapp directoy.
Your launcher class needs to make sure, that the ports of the current Tomcat are not yet in use.

Compile and Deploy the Selected Modules in java

In my application I have three java modules. I have to deploy it into the tomcat server dynamically by selecting module 1 and module 2 or module 3. The selected modules will gets packaged and form a war file and gets deployed in server without restarting. How can I achieve this? Is there any Apache products/tools or any available to do this?

The products/tools you should look at is the Tomcat Manager. The default installation of Tomcat comes with the Tomcat Manager. As the names says it can manage (deploy, undeploy, reload, start, stop) applications for Tomcat without reastart. I'm not realy sure what are your needs and how your precondition look like, but i see four ways how you may can do this:
If you already have a WAR, you can simply use the Tomcat-Manager via a Browser. Just call the manager URL (e.g. http://localhost:8080/manager/html). There you have options to upload a WAR and undeploy a application. (Before you can login, you have to edit tomcat-users.xml - just google a bit).
Use Apache Ant. Ant is a XML-based build tool for Java. With Ant you can compile your SourceCode and pack it into a WAR. If you tomcat runs local, you can copy the WAR via ant in the webapps directory of the Tomcat. Tomcat will auto-deploy it (if auto-deploy is active, as it is by default). And if you remove one WAR from webapps, tomcat will auto undeploy.
Tomcat provides a library with ant commands, to deploy the WAR via HTTP over Tomcat-Manager to the server (Tomcat Ant Commands). So if the tomcat is remote, use this command via ant.
You don't like Ant? Use the Tomcat Manager direct via HTTP. (HTTP Commands). Of course than you have to compile and build the WAR on your own.
I hope it is usefull for you.

Reduce war size for frequent redeployments(uploads) to a remote server

While development I need to frequently update my web app source code & deploy the updated war to a remote Tomcat server. Uploading a big war(25MB) takes too long(around 30 min) on my connection which is very unproductive. Is there any way I could reduce the war size ? There are a lot of external dependencies in my project. Could I deploy just the changes(may be dependencies remain intact) ?

It depends how much control you have over the upload process. If you have remote access to the filesystem, the following should work:
Upload the WAR
Let Tomcat expand it
Stop Tomcat
Delete the WAR
Start Tomcat
Tomcat should run your app from the expanded directory
Upload changed files only and replace the old ones in the expanded directory
For static files, no further action is necessary
If up update classes or JARs, you'll need to restart Tomcat

What you are asking (Could I deploy just the changes?) cannot be done. There are other things you can do though to reduce the file size of your war file:
You can place libraries in tomcat's common directory (tomcat-dir/common/lib) and remove them from your dependencies in your war file (Does Tomcat load the same library file into memory twice if they are in two web apps?).
Place static file on a cdn or another web application on your tomcat (that would require code modification though)

You can use git hooks (http://www.git-scm.com/book/en/v2/Customizing-Git-Git-Hooks). Altough, this requires a git repository on your webserver. Deployments may triggered by push events.

Actually, if exploded war deployment is an option for you then you could use kwatee. It's a free and unrestricted tool (I'm the author) with a simple web interface (or CLI automation) that can do incremental exploded war updates and many other things.