[jboss-as7-dev] Configuration conundrum with Express

Brian Stansberry brian.stansberry at redhat.com
Mon Oct 17 17:33:05 EDT 2011


On 10/17/11 4:04 PM, Scott Stark wrote:
> So the plan, and what I'll be working on this week is to have a batch
> CLI script that exists in the openshift express application repository,
> when pushed to the express server, is run against the jbossas server CLI
> interface.
>
> One issue that is coming up is the need to refer to environment
> variables for things like the interfaces/ports for socket services.
> These values are a property of the execution environment the server is
> being administered in,

I interpreted "execution environment the server is being administered 
in" as meaning where the admin tool runs. If that's correct, why are 
these a property of where the admin tool runs rather than the server 
environment?

> and activation of a mysql datasource for example
> depends on the user "embedding" the mysql cartridge into the jbossas7
> openshift application. To run the same configuration against a local
> server in jboss tools, we would need to allow for the typical
> ${env-var:default} type of syntax. Right now the CLI does not do any
> system property or environment variable replacement. I think this is a
> feature that needs to be added to allow the scripts to be portable
> across provisioning environments.
>
> On 10/17/11 10:29 AM, Max Rydahl Andersen wrote:
>>>> For the general case Scott suggested us is that we support executing
>>>> a list of .cli operations during deploy - but that would then be very
>>>> specific for JBoss tools which is why I was having high hopes for the
>>>> support for .cli archives that I believe Jesper was working on since
>>>> that would handle the deploy/undeploy cases in a way that is sharable
>>>> between the various tools - but not sure where that went.
>>> Their are major problems with a CLI deployment:
>>>
>>> 1. Guaranteeing undeploy actually undoes what it did, which may or may not be possible
>>> 2. VM crash forcing a relaunch, forcing re-running non-idempotent operations
>>> 3. Lack of visibility into what global state each CLI deployment touches
>>
>> yeah I understand that. It's the exact same problems users and devs of the various tools that need to setup and run an app on the server today
>>    - maybe large pieces of this just isn't meant to be automated.
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat


More information about the jboss-as7-dev mailing list