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
Related
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.
I have an application which consist of two http connector with different host and port. How to handle it with shared resource i.e. mule domain project.
Have a look at https://docs.mulesoft.com/mule-user-guide/v/3.8/shared-resources.
The general idea is simple:
1. Create a domain project (in AnypointStudio: New -> Mule Domain project)
2. Move your connector configuration from the project to the domain project (use cut/paste in XML, not the graphical editor)
3. Reference the domain project from your Mule project (property domain in mule-deploy.properties
And don't forget for deployment: The domain must be deployed before you deploy your project.
#Kishan Kumar Soni, The referenced documentation explains on how use the Shared Resources with mule and is not meant for single connector only. You can move your two http:listener-config into shared resources config(domain-config) file, make sure to have unique name, then reference them in your application(s) as desired. It will work.
Instead of using mule domain project (supports only sharing of connector configurations of jms, http... limited connectors). I need to share connector configuration of Object store connector between applications. I am trying to access common data in multiple applications, hence I need this. please help me.
try with session Objects you can send session data between different mule application.
You could use configuration properties through a properties file in the domain project such as
domain.properties
Example properties:
domain.value1=true
domain.value2=my text
. This file would be under the
src/main/resource
folder in your domain project.
You can refer to this property file in your application as the global configuration element, property-placeholder. Example:
<context:property-placeholder location="..\..\domains\<domain project name>\domain.properties"/>
Simply refer to the property using
${domain.value1}
This question is related to Weblogic 12c.
I have an EAR file that I want to deploy in various environments (dev, QA, pre-prod and prod). However, my application requires a username and a password (to connect to another server) and they're not the same across the four environments. I don't want to package 4 different property files in 4 different EAR files. I want a single generic EAR file. Beside, I don't want to handle the prod password during packaging.
Ideally, I'd like the admin of each environment to provide the appropriate username nad password for the environment. Unlike Tomcat, Jetty or JBoss(?), I think it's not possible for a WebLogic Admin to specify this information in a way that it will become available under the java:comp/env JNDI context.
How can an application obtain some admin-defined configuration strings from Weblogic?
BTW, it's not a username/password for a JDBC connection.
From what I understand, you need to change parameters based on the environment you are using right?
If you would like to override parameterss on the fly you can use WebLogic deployment plan concept.
Did you mean that you need to provide username/password to start-up the application?
If so, you may accomplish that by creating a script with WLST http://docs.oracle.com/cd/E15051_01/wls/docs103/config_scripting/using_WLST.html
As far as I know, the WebLogic way is to
Define your username/password as env-entry in the deployment descriptor
Deploy your application together with the plan.mxl whereas each environment admin maintains his own envrionemnt-specific version of the plan.xml
That way you get them into /comp/env/config
More details here: http://docs.oracle.com/cd/E11035_01/wls100/deployment/config.html
Only drawback known to me: plan.xml will always contain the unencrypted password but as the admin knows the password anyway and this is "his" file on "his" maschine that should be fine.
In JBoss 4.2.3 we could configure items in
[jboss_server]/deploy/jboss-web.deployer/conf/web.xml
which would be adopted by all applications deployed. We've used this to configure context params, servlets, and default tag files.
We have dozens of apps deployed in war files, and this a very handy tool.
How is this accomplished in JBoss 7.1.1? I've googled and searched but can't seem to find the solution.
You could try web fragments (part of Servlet API 3.x). You'll be able to apply the same set of filters, mappings, listeners, variables to each web app's context using one META-INF/web-fragment.xml file (inside some WEB-INF/lib/my-common-context.jar, so it'd be easily managed as a simple dependency).