no-eclipse tomcat env variable equivalent - eclipse

I can set an environment variable with Eclipse when I click on the Tomcat Server and then Open Launch configuration -> Environment -> Variable, Value. What is no-gui, no-eclipse textual-xml equivalent of this variable setting?

Context Parameters
See: Context Parameters section of The Context Container page.
You can configure named values that will be made visible to the web application as servlet context initialization parameters by nesting <Parameter> elements inside this element. For example, you can create an initialization parameter like this:
<Context ...>
...
<Parameter name="companyName" value="My Company, Incorporated"
override="false"/>
...
</Context>
This is equivalent to the inclusion of the following element in the web application deployment descriptor (/WEB-INF/web.xml):
<context-param>
<param-name>companyName</param-name>
<param-value>My Company, Incorporated</param-value>
</context-param>
but does not require modification of the deployment descriptor to customize this value.

If you're using gnu-linux operating system you can edit the catalina.sh script to export you environment variable. First line of the script (after comments, of course) should be
export variableName=variableValue
The credit is for Lucas that told me how to do.

If you meant arguments passed to the launching of your servlet context, see the Answer by miku.
Environment Entries
If you meant the Environment Entries feature, use <Environment> rather than <Parameter> seen in that other Answer.
Here is an example where I set a flag signaling if I am running the web app for development, testing, acceptance, education, or production.
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<!-- Domain: DEV, TEST, ACPT, ED, PROD -->
<Environment name = "work.basil.example.deployment-mode"
description = "Signals whether to run this web-app with development, testing, acceptance, education, or production settings."
value = "DEV"
type = "java.lang.String"
override = "false"
/>
</Context>
You have your choice of a few places to place such XML. For this example, we would want to externalize the file, keeping it outside the WAR file containing our web-app. By externalizing, we can deploy our WAR to any of the dev, test, acpt, ed, or prod servers without needing special builds or manual editing. So for this purpose I like to use the feature of Tomcat allowing for an XML file named the same as the context. The file is place in the conf folder, in which you create nested folders named after the Tomcat engine and the host. For example, on my development machine that would be my_tomcat_base_folder/conf/Catalina/localhost/example.xml where example is the name of my context, Catalina is the engine name, and localhost is the host name (not using a domain name while in development).
The syntax of the above XML is Tomcat-specific. For use in Servlet-standard places, such as the /WEB-INF/web.xml file, the equivalent as documented in the Servlet 4 spec section 14.4.21 would be:
<env-entry>
<env-entry-name>work.basil.example.deployment-mode</env-entry-name>
<description>Signals whether to run this web-app with development, testing, acceptance, education, or production settings.</description>
<env-entry-value>DEV</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

Related

Accessing environment variable value from service fabric environment xml file

I have a scenario where I need to read an environment variable from the machine where my Service Fabric application is deployed.
More specifically in my cloud.xml (environment file) I want StorageConnectionString to use the value from one of the environment variable that is set on the machine by some other external tool.
<?xml version="1.0" encoding="utf-8"?>
<Application xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="fabric:/AppFabricName.ServiceFabric" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Parameters>
<Parameter Name="StorageConnectionString" Value="%ENVVARIABLE%" />
</Parameters>
</Application>
Is the above valid ? Did not work when I tried even though running SET on cmd prompt did show that variable exists.
It's not straight forward, but here's a way:
Specify a setup entry point (a new executable or script) to read the environment variable and write it to a file in the application's work directory.
When the main entry point comes up, read the file from the work directory.
If you are passing the data via configuration files(or parameters) at deployment and accessing it via code using Context.CodePackageActivationContext.GetConfigurationPackage‌​Object("Config") , the right way should be using <Parameter Name="StorageConnectionString" Value="[ENVVARIABLE]" /> (note that it is encolsed by [ ]) and have a configuration file with a variable called ENVVARIABLE and set the overrides to your service. You should not need to set environment variables, environment variables is other thing.
Please take a look at this SO question to check if will solve the problem.
If your plan is getting an environment variable already set in the machine, unfortunately SF does not support Environment Variable Replacement using tokens like %ENVVARIABLE%.
even though running SET on cmd prompt did show that variable exists.
The other process that changes the environment variable, if it just use the default set, it will set their own process environment variables, to be available to other processes, it has to update environment variable on Machine or User scope(assuming they run on same user), this is why you can't see from command running SET variablename
...
Assuming the variable is set correctly and it is a machine scope variable...
When the Environment Variable is set before the process start, I would suggest you setup an EntryPoint Script to set it at startup, like you would do to a guest executable.
See a NodeJs example here
You could maybe also do write to file and read from your app as Loek suggested, but I think it would be too complicate for too litle.
In case the environment variable is set after the process started, or if it changes later, you should get it from within your application directly instead, you could just use:
System.Environment.GetEnvironmentVariable(variableName,EnvironmentVariableTarget.Machine);
And you pass the variable name via config.
In both cases your user\process must have permission to read Environment Variable from Machine Scope

Different Endpoint Certificates Per Environment in Service Fabric

I have a service fabric application that exposes an SSL endpoint. I would like to use a different certificate based on the environment. I'm trying to do this with parameters in the ApplicationMainfest.xml file in the same way that I specify other things, such as instance counts. However, parameters appear not to be working for this. I'm wondering if this is actually true and if there are certain things that you cannot parameterize. Also, is there any way to specify a different certificate based on the environment?
Here are the relevant pieces from my application manifest:
<Parameter Name="CERTNAME" DefaultValue="MyCert" />
...
<Certificates>
<EndpointCertificate X509FindValue="..." Name="MyCert" />
<EndpointCertificate X509FindValue="..." Name="SVSSL" />
</Certificates>
<Policies>
<EndpointBindingPolicy EndpointRef="ServiceEndpointHttps" CertificateRef="[CERTNAME]" />
</Policies>
On deployment, I get the following error:
Register-ServiceFabricApplicationType : The CertificateRef '[CERTNAME]' in EndpointBindingPolicy is invalid. There is no matching Certificate in the corresponding ApplicationManifest.
Today the certificate value itself is parameterizable but not the Ref. So instead of changing the reference or the name, you would parameterize the X509FindValue and keep the endpointbindingpolicy the same.
As a note, just any time you run into something you want to parameterize but can't figure out how to do it, there are a few options. Consider for example most things in the Service Manifest, like the port that the service listens on (if you have it statically configured). There are some other ways around this:
Create different manifests (service manifests or application manifests) and replacing them when creating the application package for a given environment
Using something during your build/deployment stages (such as the Tokenizer Task in VSTS) to replace a stub value with the actual value given the environment that the package is being crafted for
Move most of the endpoint configuration stuff to settings.xml and replace those values via the normal application parameter/override behavior. This would mean taking on the work of configuring your endpoints yourself, however.

JBoss 7.1.1 changing JNDI binding in runtime

In JBoss 7.1.1 in standalone mode all JNDI bindings are configured in standalone.xml file in jboss:domain:naming:1.1 subsystem. According to documentation standalone.xml cannot be modified when server is running. I've tried to use JBoss CLI but I don't know how to write/modify resource.
How to change value in JNDI without restarting jboss?
Should help you: https://docs.jboss.org/author/display/AS71/JNDI+Reference
Topic - Binding entries to JNDI:
An example standalone.xml might look like:
<subsystem xmlns="urn:jboss:domain:naming:1.1" >
<bindings>
<simple name="java:global/a" value="100" type="int" />
<object-factory name="java:global/b" module="com.acme" class="org.acme.MyObjectFactory" />
<lookup name="java:global/c" lookup="java:global/b" />
</bindings>
</subsystem>
To add these entries via the CLI:
/subsystem=naming/binding=java\:global\/mybinding:add(binding-type=simple, type=long, value=1000)
To see all all options that are taken by the add command (this can
actually be used to get the description of any CLI command):
/subsystem=naming/binding=*:read-operation-description(name=add)
Have not tried, but i hope this helps!
UPDATE - with tested examples:
Add JDNI name binding java:global/a:
/subsystem=naming/binding=java\:global\/a:add(value=10,binding-type=simple,type=java.lang.Integer)
Read existing JDNI name binding java:global/a:
/subsystem=naming/binding=java\:global\/a:read-resource(include-defaults=true)
Modify JDNI name binding value java:global/a:
/subsystem=naming/binding=java\:global\/a:write-attribute(name=value, value=20)
Remove JDNI name binding java:global/a:
/subsystem=naming/binding=java\:global\/a:remove()
Executing command directly from shell:
./jboss-cli.sh --connect --command="/subsystem=naming/binding=java\:global\/a:read-resource(include-defaults=true)"
The question has a lot of views so I'll answer to it. Inspired by #mik response I've figured out that to change value of some JNDI key e.g. java:jboss/api/key to newApiKey run JBoss CLI and execute:
connect
/subsystem=naming/binding=java\:jboss\/api\/key/:write-attribute(name=value,value=newApiKey)
The change will be immediately visible on server and also stored (updated) in standalone.xmlso it won't get lost after server restart.
I was looking exactly for how to add or modify a JNDI binding at runtime, but I needed to to do this in a Wildfly 9 domain (cluster) configuration (not standalone), which is pretty much the same configuration as JBoss 7. However, I couldn't figure out a way to effectively apply changes without restarting all servers.
To start with, enter the JBoss command line interface and connect to your server domain controller:
./jboss-cli.sh
connect
First, you need to find which profile is active on the server group, so as, on the server root /, enter the following commands:
cd server-group=
ls
Afterwards, you should enter the only server group shown in the listing command (ls) by typing cd {{your_server_group_name}}, then type ls again and look for an entry named profile to check which one is active. Let's consider full-ha as an active profile for our example.
Next, go back to the root configuration folder / by typing cd .. and enter the following commands to navigate and view all JNDI bindings available with their current values:
cd profile=full-ha/subsystem=naming/binding=
:read-resource(recursive=true)
By doing this, you'll be able to see all available JNDI bindings and their attributes, if you want to list only binding names, type ls instead of the last command.
In order to modify a binding, type cd and the name of the binding listed in the previous command. Let's suppose you want to change the value of a binding named java:/webservice.url, then you should enter
cd java\:\/webservice.url
Notice that is necessary to quote some characters in your binding name such as : (colon) and / (slash) with a backslash (\).
To modify an attribute within this binding you should use the :write-attribute command. In this example, let's suppose you want to modify (or add) an attribute named "value" with its content as "this is a value":
:write-attribute(name=value,value="this is a value")
So as to apply this change, you'll need to restart all servers in the cluster by typing the following command:
/server-group={{server-group-name}}:restart-servers
If you want to know more commands to add or remove JNDI bindings check this jboss-cli snippets page
This configuration has been tested successfully in Wildfly 9.0.1

AppSettings values not being picked up in web.config in subdirectory

We have a set of WCF Services being hosted in IIS. In our architecture, we have different instances of the service that vary in configuration hosted in subdirectories under the root.
I have a Web.Config in the root that has some configuration information in the AppSettings section. Specifically, it looks like this:
<appSettings>
<add key="Environment" value="Local" />
</appSettings>
In the different subdirectories, I add another Web.config which adds other settings that are specific to the services in that subdirectory.
<appSettings>
<add key="Subdir" value="ABC" />
</appSettings>
However, when I invoke a service (.svc) file in the subdirectory, there is only one value in the ConfigurationManager.AppSettings collection ("Environment"). The "Subdir" key is nowhere to be found. (BTW, the code is written using ConfigurationManager, but I've also tried using WebConfigurationManager, and the result is the same.)
The documentation on MSDN clearly says that the Web.config files in nested directories are supposed to be cumulative. So why isn't my "Subdir" key showing up in that collection?
Thanks in advance for any help you can give me.
For the benefit of anyone else that encounters this, I found the answer.
Even though this app is a service running under IIS, and is being accessed through IIS, the point where this config element is needed is deep down in a derived class of System.ServiceModel.ServiceHostFactory. At that point, HttpContext.Current is null, so the ConfigurationManager has no access to Web directory structure information, and has to depend simply on the application configuration, which is at the top level.
So our solution is to make each Subdirectory an IIS application, and give it all of its own config information in one place.

How to run multiple instances of JBoss in a one single machine?

I need to run multiple(more than 4) instances of JBoss server on a single machine.
I am using JBoss 4.2.3 GA.
I found the answer. We have to configure the jboss-service.xml to run multiple instances in the same machine.
We may need to keep the same "default" instance same as it is under the JBOSS_HOME\Server.
We have to create another folder say "instance2" under JBOSS_HOME\Server.
Copy all the contents from JBOSS_HOME\Server\default to this newly created folder.
Now goto conf folder under JBOSS_HOME\Server\instance2 directory.
Edit the jboss-service.xml.
Search for mbean code="org.jboss.services.binding.ServiceBindingManager" in this configuration file.
By default this xml tag is commented. We have to un comment it and change the value ports-00 to ports-01.
Then start this instance2 jboss instance. We can access this application by using the port number 8180.
We can go for at maximum of 3 instances with this way.
To run more than this we have to add some more running tags in
JBOSS_HOME\docs\examples\binding-manager\sample-bindings.xml.
You can make things a lot simpler by simply changing the IP that the server is bound to.
You will need to copy the entire jboss folder several times and configure run.bat to use the -b parameter on startup.
If this is a Windows server and you're running jboss as a service, you might want to edit the service.bat for each instance too so that the servers all have different names in the services control panel.
Part of the problem we ran into when trying to use different HTTP ports was that jboss uses 'lots' of ports for different purposes and it was a pain to edit all of these port numbers to be unique on each instance. By changing the bind address you can avoid this problem entirely.
Create multiple loopback adapters and bind each ip address to different instance.
No need of changing port.
RK
1) Copy the default folder with new name: instance name
2) In jboss-service.xml Uncomment the ServiceBindingManager mbean and change the ServerName to ports-01 or 02 or 03 e.g:ports-01 and ports-01/02/03 configuration should be there in sample-bindings.xml(present in docs/examples/binding-manager) And make the changes in all the ports mentioned under ports-01/02/03 tags, So that ports will not get conflict. Remember the server will run on the binding port like 8080/8180/8182.
from cmd promt go to the bin folder and run the instances with cmd:
run -c instancename
Running multiple instances of JBoss on the same server:
We should keep the "default" instance same as it is under the **JBOSS_HOME\Server
Copy the default folder with new name (instance name) say default2 under JBOSS_HOME\Server. Copy all the contents from JBOSS_HOME\Server\default to this newly created folder.
The binding service manager needs to be enabled in conf/jboss-service.xml for instances that are not using the default ports.
a. (i.e.) In the copied instance, go to conf folder under JBOSS_HOME\Server\default2 directory. Edit the jboss-service.xml.
b. Search for mbean code="org.jboss.services.binding.ServiceBindingManager" in this configuration file.
c. By default this xml tag is commented. We have to uncomment it and change the value ports-00 to ports-01.
In the same file, Under "Socket transport Connector", in the "Configuration" section, serverBindPort must be changed to another value or it will conflict with the default (4446).
<mbean code="org.jboss.remoting.transport.Connector"
name="jboss.remoting:service=Connector,transport=socket"
display-name="Socket transport Connector">
...
<attribute name="Configuration">
...
<attribute name="serverBindPort">25447</attribute>
...
In default2/deploy/ejb3.deployer/META-INF/jboss-service.xml, for the remoting.transport.Connector mbean, port 3873 must be changed to another value or it will conflict with the default.
<mbean code="org.jboss.remoting.transport.Connector"
name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
<depends>jboss.aop:service=AspectDeployer</depends>
<attribute name="InvokerLocator">socket://${jboss.bind.address}:25874</attribute>
...
In default2\deploy\jboss-web.deployer\server.xml
set redirect port value to the one configured in step 4
<Connector port="8180" address="${jboss.bind.address}"
maxThreads="250" maxHttpHeaderSize="8192"
emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="25447" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />
Also, the port value configured in step 5
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="25010" address="${jboss.bind.address}" protocol="AJP/1.3" //change the connector port value to avoid conflict
emptySessionPath="true" enableLookups="false" redirectPort="25874" /> // port value configured in step 5
In summary, the directory structure for setting up two other instances would be something
like the below with modifications in the filenames in bold.
$JBOSS_HOME/server/default
$JBOSS_HOME/server/default2
$JBOSS_HOME/server/default2/conf/jboss-service.xml
$JBOSS_HOME/server/default2/deploy/ejb3.deployer/META-INF/jboss-service.xml
$JBOSS_HOME/server/default2/deploy/jboss-web.deployer/server.xml**
$JBOSS_HOME/server/default3
$JBOSS_HOME/server/default3/conf/jboss-service.xml
$JBOSS_HOME/server/default3/deploy/ejb3.deployer/META-INF/jboss-service.xml
$JBOSS_HOME/server/default3/deploy/jboss-web.deployer/server.xml**
7.From command prompt go to the bin folder and run the instances with cmd:
run -c instancename
In this case, it is: run -c default2
And applications accessed with url’s like:
http://localhost:8080/myapp/
http://localhost:8180/myapp/
http://localhost:8280/myapp/
Note: We can go for maximum of 3 instances with this way.
To run more than this we have to add some more running tags in JBOSS_HOME\docs\examples\binding-manager\sample-bindings.xml.
I used this article to install mine.
http://wiki.adempiere.net/Setup_2_Adempiere_JBoss_server_in_1_physical_server
You should create different services to control the adempiere servers.
Also if you work with jasper report, use unique file names for reports or you will face permission denied exception.
Ex : if you attach "report.jrxml" to two servers. Server will create /tmp/report.jrxml tmp file.
The second server will also try to create the same file and get crashed
Copy complete JBOSS setup to new location, and start new server with offset option, which will start server on existing ip and changing port to previously_configured_port+offset
standalone.bat -c standalone-full.xml -Djboss.socket.binding.port-offset=100
This command will make default jboss console 9990 to 10090
Now you can add your war file in new deployments folder and start deployment on new port
The quickest and easiest way that comes into mind is simply configuring multiple IP addresses to the hosting machine. Then you can use the different IP addresses to bind to each instance. Doing this means you don't have to change any default ports and allows for an easier environment to manage.
We can easily do this on JBOSS EAP
For first instance, just start the JBOSS as it is.
for the second instance,
Copy the JBOSS home folder to a different location.
go to standalone/configuration/standalone.xml. go to the section(at bottom of the file) and set port-offset value to some value(EX: 10000) which doesn't have any port binding issue on currently running application. Here the default port-offeset value is 0.
start the second instance as usual .