Galleon feature packs and configuration

[Mike Douglass]

I want to be able to configure an installation of wildfly + bedework using galleon.

For example - I have a datasource with a parameter like this:

<param name="connection-url" value="${org.bedework.db.url.carddav}"/>

and I define that property in the system-properties section: which is set from a system property with a default.

I'd like the installer to be able to set that property at installation rather than having to edit a file afterwards.

I believe it's related to the config section in the feature pack build - something like?

<config  name="???">
   <feature spec="subsystem.datasources">
     <feature spec="subsystem.datasources.data-source"> 
       <param name="data-source" value="CardDS"/>
       <param name="connection-url" value="${org.bedework.db.url.carddav}"/>
     </feature>
   </feature>
</config>

I have things set up so that bedework is a feature pack with a bunch of layers representing separate functionality (carddav, self-registration etc etc). There are about 6 layers with datasources any combination of which might be installed.

Currently I have the galleon parameters for example

install org.bedework:bw-wf-feature-pack:4.0.0-SNAPSHOT  --layers=bw-calendar-rw,bw-carddav,...

So the 2 questions are:

1 - can I make a layer depend on a config or have a specific config applied to a given named layer?

2 - Can the installer create their own configuration and have it applied by the galleon cli?

[Jean Francois Denise]

Hi Mike,

I am not sure I got your question. I will make an answer with a typical way to have an attribute value to depend on a system property with a default value:

<param name="connection-url" value="${org.bedework.db.url.carddav:my-default-value}"/>

If the system property org.bedework.db.url.carddav is not set, the default-value is used.

2 - Can the installer create their own configuration and have it applied by the galleon cli?

The galleon CLI tool doesn't have support to invoke a given CLI script after installation. You could automate in a bash script the execution of the 2 tools.

Instead I think that you could define a properties file to persist the system properties values and use it when starting the server. Something like:

standalone.sh --properties=myproperties.properties

JF

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/84da7220-2225-411d-963f-429af7719dc3n%40googlegroups.com.

[Michael Douglass]

Thanks for the response.

I've done more or less as you describe below. I was left with a couple of cases that currently need replacement at install time - or editing afterwards. One is a soap service location embedded in a wsdl document. Property replacement at run-time doesn't work there so I hoped ther was a way to provide site specific values at install time through galleon.

There may be alternative approaches for that particular use case.

You received this message because you are subscribed to a topic in the Google Groups "WildFly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wildfly/Xv48KXZtPkM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/d04cbdac-b31b-4752-aaba-42b7391a5298%40redhat.com.