What is the best practice for using JBoss tools to develop ee6 apps that are tested both locally and against the OpenShift express environment?

What I have done so far is to create the local project which I test against a local as7 web profile, and then export the war to the express git repository deployments directory where I can push the binary up to the express environment.

I'm myself trying to explore various "best practices" but its not easy because openshift and as7 does things in similar but still different ways.

And it all depends if you are using the "source" approach of letting openshift build its deployment or the "binary" approach you mention above.

Until M4 (next jbt release) your approach is probably the simplest, but in M2/M3 you can also create an AS 7 server adapter in which you toggle the "Server is externally managed. Assume server is started" On, set the "Use Custom deploy folder" to the "deployments" folder of your openshift repo and then the only thing you need to do is to do the git commit/push (the adapter will make sure there is a deployment with proper .dodeploy file).

In M4 we plan to push the "source" approach and create an server adapter which will allow Run As... to work without additional configuration

and if we can make it a "binary" server adapter which will maintain its own git checkout and and do commit/push to openshift via the "deployments" folder (basically what you do but just automated).

Where do I setup the server adapter? I see the jboss tools runtime detection, but don't really find the as7 server adapter or settings your talking about.

There are a number of issues that I'm facing that we should try to make easier.

1. I can easily run all 5 wars in the same local runtime each with unique localhost based urls using the context-root resulting from the war deployment name. These are mapped to 5 different express applications and need to have an updated jboss-web.xml that specified a / context-root since each application already has a unique dns name, for example,

Now I can certainly just use the same default context root of idp so that the url for the express app is http://idp-sstark.dev.rhcloud.com/idp/, but I'm looking into things users would want to do with a local vs paas deployment of their application. Currently I achieve this by exporting the war to the express app deployments directory, and then run an ant fixup script that overwrites the ipd.war/WEB-INF/jboss-web.xml with another that overrides the context-root. I know I mentioned the need to have an exported context-root differ from what is deployed locally in another thread. If in the M4 there could be a setting that allowed one to specifiy an alternate jboss-web.xml (like the jboss-web-express.xml I use), that would overwrite the current WEB-INF/jboss-web.xml whent the war is exported, that would be helpful.

2. The application I'm working on have references to each other, and as such, have pages/configuration that reference either a property or a default localhost based url. For example:

Now I set the idp.url and employee.url settings in the express app .openshift/conf/standalone.xml server configuration file. It would be nice if there was a dual notion for the jboss as7 server runtime that allowed you to edit a local vs paas view. Right now there is an XML Configuration section under the server with just a Ports section. If there were Local and PaaS sections where two standalone.xml configuration could be managed that would be helpful.

Select existing server adapter, Ctrl+C + Ctrl+V to copy/paste it and you have a clone you can edit.

Once you have the new server, double click it and the settings I talk about is on the first and second page of that server editor.

1. There really aren't a good way of doing this "conext dependent deployment" that doesn't end up being a giant feature specific hack.

jboss-web.xml is probably only just one of many parameters that you would want to change between your PAAS/Local deployment.

Is the context root really something that should be set in the deployment ? Can't we find a way to have that be a separate configuration/deployment ?

Then you could deploy the *same* archive to multiple servers - the deployment could of course have a default specified, but should be possible to overwrite/reconfigure part of the server.

2. "dual notion for the jboss as 7 runtime" -> create two servers, one for local, the other for the PAAS view. That's what they are there for.

Beyond that standalone.xml configuration/editing is not something we have looked into yet - mainly because it was expected the Web/CLI console would be used to manage it and until now AS (pre AS 7) config files have been changing so often that it was hard to support well.

We could add some xml transformations into this but would be greater if there was someway we could actually use the management API against these xml files without having to start an AS 7 on them.

1. There really aren't a good way of doing this "conext dependent deployment" that doesn't end up being a giant feature specific hack.

jboss-web.xml is probably only just one of many parameters that you would want to change between your PAAS/Local deployment.

Is the context root really something that should be set in the deployment ? Can't we find a way to have that be a separate configuration/deployment ?

Then you could deploy the *same* archive to multiple servers - the deployment could of course have a default specified, but should be possible to overwrite/reconfigure part of the server.

Yes, I do think we have to change what gets exposed to the user to a series of admin commands that get played against the server to setup the the deployment and other PaaS vs local settings. The admin configuration file is not really the best thing. I'll start looking into this more seriously after JavaOne.

2. "dual notion for the jboss as 7 runtime" -> create two servers, one for local, the other for the PAAS view. That's what they are there for.

Beyond that standalone.xml configuration/editing is not something we have looked into yet - mainly because it was expected the Web/CLI console would be used to manage it and until now AS (pre AS 7) config files have been changing so often that it was hard to support well.

We could add some xml transformations into this but would be greater if there was someway we could actually use the management API against these xml files without having to start an AS 7 on them.

The problem I seemed to be having was using the .openshift/config/standalone.xml as the remote server configuration. I'll take another stab at it and see where I was running into a problem. I agree that exposing this file really is not the best admin api for trying to manage the deployment's environment.

btw. in the current state of things the best thing would be if when the pom.xml is being used on openshift side that could be detected somehow and used as a way to enable the proper profile in which you can do the proper "deployment dependent" switches.

This doesn't solve the problem of direct binary deployment from eclipse tooling, but its the best scalable approach I can forsee right now.

Select existing server adapter, Ctrl+C + Ctrl+V to copy/paste it and you have a clone you can edit.

Once you have the new server, double click it and the settings I talk about is on the first and second page of that server editor.

I don't seem to be able to set this up the way I want. The issue is I want to be able to associate the openshift app git repo .openshift/config/standalone.xml as the configuration file against which the XML Configuration settings work with. Even if I set the XPath Root Directory to be the repo/.openshift dir, this gets reverted to some path relative to the as7 install it appears. I was able to get around this by adding a link under the server root to the repo/.openshift/config directory, but it would be good just to be able to specify the Root Directory as an absolute path.

The xml configuration does not appear to be working even with the workaround, and it really is not what we want to expose going forward anyway. I'll create a feature request to support a "CLI Batch" file that contains a collection of admin commands that will be run through the cli interface. There will need to be a remote/local notion to support the openshift case of having this file be in the application git repo and applied when pushed vs applied to a local server by invoking the cli tool.