I've tried to learn the JBoss Arquillian, by following the formal document and got confused about the configuration, the arquillian.xml. Since it is mentioned once here.
Even I also found that there is a specific configuration describes at the container adapters section. It does not cover all elements/properties, e.g. engine and its property list, defaultProtocol, extension and group.
I'm worried and wondered, if there is any further or full explanation for this configuration file or not. Could you please help to shed some light on this configuration?
There's no single page in the Arquillian Reference Guide that contains your answer. This is partly because of the modular and extensible nature of Arquillian - extension can have their own configuration elements and properties.
To start with, the properties for containers are in the Container Adapters Section. Every adapter has it's own page where the container configuration is detailed. For instance, JBoss AS 7 has it's own page for it's container configuration (see the Configuration section on the page), and so do other containers.
Usually, you wouldn't need to configure the protocol yourself, for the values are usually managed by Arquillian, and usually do not require any overrides to be provided via arquillian.xml. But if you need them, they're in the Protocols section and in the child pages.
A group is merely a collection of containers, to used in cases where the container does not support clustering by default. You merely need to list multiple container configurations in a group element, as shown here.
Extension configuration is typically found in the Extensions child-pages.
The defaultProtocol element does not have any page of it's own. It is used to override the protocol specified by a container adapter, for all tests. There are only a few cases where you would need to use this element, most notably when you need to use the Servlet protocol instead of the JMX protocol for JBoss AS 7 (because the Servlet protocol of Arquillian is a more widely used and tested protocol than the JMX one).
A typical use of defaultProtocol would look like:
<defaultProtocol type="Servlet 3.0" />
where the type is the name of the protocol - "Servlet 2.5" and "Servlet 3.0" are valid values. You may also need to add the protocol dependency to your classpath when you change the default protocol of the container.
Related
I can use puppet to set up my apache httpd and add virtual hosts and load needed modules. I also know how to add custom configuration within a virtual host using the customconf-value but...
How do I configure in my pp-file to add my custom configuration in the main server config context? (I.e. outside of the virtual hosts)
I am using the standard apache module in puppet https://github.com/puppetlabs/puppetlabs-apache
I have read the documentation several times and also tried following the broken links to for example apache::mod documentation (to see if there is some similar value like customconf but... with no success).
How do I configure in my pp-file to add my custom configuration in the main server config context? (I.e. outside of the virtual hosts)
The reference documentation for the module is here: https://github.com/puppetlabs/puppetlabs-apache/blob/main/REFERENCE.md, or you can access it via the Forge here: https://forge.puppet.com/modules/puppetlabs/apache/reference.
Those document the plethora of parameters of the apache class, which expose a wide variety of Apache's configuration properties. You can manage most of the most common (and many of the less common) Apache configuration details by setting appropriate values for these class parameters.
They also document a plethora of classes that you can declare to adjust which modules are enabled, plus a native resource type (a2mod) and a defined-type wrapper apache::mod that you can use to configure modules that do not have a pre-built class.
And they document several public defined types that you can use to customize your configuration (including, but not limited to, vhosts). Of these, apache::custom_config is the most general, as it allows you to manage drop-in files containing more-or-less arbitrary Apache configuration.
Trying to read about the precedence of loading several properties in Spring cloud config, I am not finding my case to figure it out which is the precedence of properties. My case is the next:
I have the next properties in the spring cloud config application:
application.properties
application-dev.properties
nameOfApplicationXX.properties
nameOfApplicationXX-dev.properties
I am launching the app nameOfApplicationXX with the dev profile. My case is that application-dev.properties has one property and this property is not being overriden by the same property present in nameOfApplication.properties. So, application-dev.properties has preference over nameOfApplicationXX.properties because the first one is specifying a profile?
Which is the precedence of each one? Do you know the docs reference because I am not finding it
Thanks
If I understood your problem correctly then the below is the solution I have found from the Spring Cloud Config document reference:
"If the repository is file-based, the server creates an Environment from application.yml (shared between all clients) and foo.yml (with foo.yml taking precedence). If the YAML files have documents inside them that point to Spring profiles, those are applied with higher precedence (in order of the profiles listed). If there are profile-specific YAML (or properties) files, these are also applied with higher precedence than the defaults. Higher precedence translates to a PropertySource listed earlier in the Environment. (These same rules apply in a standalone Spring Boot application.)"
Spring Cloud Config reference link : Documentation
Note: By seeing the above problem statement I can say that you are using file based profile in Spring cloud Config server. The Spring Cloud Config server will return List of Property Sources for each type as a classpath resource properties.
To override the the default implementation I have implemented the same and reference code is available in gitHub link : Source Code
Not a similar issue but may help you : reference issue
Hope this will help you to fix the above mentioned problem statement.
We have a multi-tenancy website. We are trying to use social share components where the url needs to be shared. Since we have a dispatcher configured, we are picking up the domain from a context aware configuration. How do we use different domains for environments based on run-modes
I have tried to use different ca-config folder for each environment but this is not ideal.
Sling context aware configurations don't work on run modes. For your current requirement you should be using Externalizer service which works basis sling maps, request origin and OSGI configs based on what method you choose.
https://helpx.adobe.com/in/experience-manager/6-3/sites/developing/using/externalizer.html
https://helpx.adobe.com/experience-manager/6-4/sites/developing/using/reference-materials/javadoc/com/day/cq/commons/Externalizer.html
You can use Day CQ Link Externalizer which is available in the OSGI configurations, http://localhost:4502/system/console/configMgr.
It is an OSGI service that allows you to programmatic-ally transform a resource path into an external and absolute URL. You can configure this configuration for different run modes
You can also use a 2-step approach. 1st you create a Run-Mode dependent OSGi config. 2nd you use the built-in Override via OSGi configuration.
See here: https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration-override.html#override-via-osgi-configuration
i need to be able to configure JBOSS as 7.2 to only startup the services required in the project.
what is the best aproach to customize JBOSS as 7.2 configuration and set it to a user defined configuration ?
i'm intending to use :
JAAS , EJB , JSF ..
If I understand your request correctly,
it would be removing the unnecessary subsystems.
In standalone, you can configure multiple xmls per your use, and decide the standalone config to use at startup, which would allow you to adapt to various needs quickly.
In domain, it's even easier as you can define various profiles, each of them with specific subsystems present or not, and then assign the necessary profile to your server group.
Removing subsystems through xml modification or CLI is simple,
adding them through CLI sometimes require figuring some of the "default" expected entries for recreation of the subsystems, but once figured out, is easy also.
Key element in your case is to make sure you do not clean up too many of the subsystems, as they sometimes have dependencies to one another.
Is it possible to add a custom object (String or URL) to JNDI using Weblogic Server Administration Console (Weblogic 10.0) or by editing server's configuration file (config.xml)?
I don't think so. Quoting Load objects in the JNDI tree:
Using the Administration Console, you can load WebLogic Server J2EE services and components, such as RMI, JMS, EJBs, and JDBC Data Sources, in the JNDI tree.
And indeed, I couldn't find a way to add a String or URL using the console.
AFAIK, the standard way is to put an env-entry in your deployment descriptor (web.xml, ejb-jar.xml):
<env-entry>
<env-entry-name>string/foo</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>foobar</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>url/bar</env-entry-name>
<env-entry-type>java.net.URL</env-entry-type>
<env-entry-value>http://foobar/</env-entry-value>
</env-entry>
I have reached this with exactly the same problem. In Websphere, for example, I can add arbitrary parameters such as temporary directories, passwords, and other information to JNDI without having to recompile/rebuild the EAR.
I've searched for a while and seems Weblogic lacks this feature. What I did was write a helper class that first searches JNDI for a given configuration key, and if it doesn't find it then falls back to searching environment or system variables.
Perhaps this could be enhanced to also search for those properties prefixed by the application's name or context root, discovered at runtime, to avoid name clashes when multiple instances of the same EAR are deployed.
You can but you will lose high availability if using cluster. See:http://docs.oracle.com/cd/E11035_01/wls100/jndi/jndi.html#wp475702