I would like to have optionally supplied information available to my webapp when deployed to Websphere (we are using 8.5) via the application's JNDI context.
I know that I can put a resource-ref or resource-env-ref in my web.xml but when I do that WAS will require me to supply a binding for it and deployment time.
My application will look in JNDI for certain values and adjust its behavior if found, but will function fine with default behaviour if it does not find values in JNDI. How, in WAS, do I supply a binding (just for a string or a URL) for my webapp without declaring a dependency on it in a resource-ref or resource-env-ref in my web.xml.
I know how to do this in Tomcat, I just put a Environment entry in the context.xml, like this:
<Environment
name="com.myorg.config"
value="http://localhost:8081/suff"
type="java.lang.String"/>
You can use an #Resource String lookupName; to accomplish the same in a portable manner. You will be prompted for a value at deployment time, but you can specify nothing, which will cause no value to be injected.
Related
I have a lot of Websphere servers with different JNDI name of my DB connection so I have to build many ears files for each server. I'd like to do something like this:
<bean id="dbDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="${SPECIFIC_JNDI_NAME}"/>
</bean>
How can I create this SPECIFIC_JNDI_NAME variable?
The proper Java EE way to do it, is using resource references in your code like: java:comp/env/jdbc/myDSRef, then this resource reference is bind to actual JNDI name during the installation process.
You either define references via #Resource tag, or entry in the deployment descriptor (web.xml or ejb-jar.xml).
You map it to the JNDI name via admin console, wsadmin installation script, or ibm-web-bnd.xml file placed in the WEB-INF folder.
It is possible to use references with Spring.
This is the wrong way to go about it. One advantage of JNDI is that you can bind objects (in this case a datasource) under one JNDI name without a care for where it came from, how it was instantiated, etc. as long as it was there at the time it was first accessed.
You (or whoever configures the JNDI names) are basically trying to take away that advantage by binding different datasources on different JNDI names.
A workaround could be to bind the 'custom' name to a 'standard' JNDI name such that your application can still refer to the 'standard' name and the onus for providing the right bean is on those who configure the JNDI but really, if you go that far you can also just give the datasource the standard name. Also, I'm not sure that is even possible in JNDI, I just know that it used to be possible in Spring's own configuration.
I am trying to set up JNDI lookup in web application to be deployed in Tomcat 7. I have specified following properties in jndi.properties file:
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory,
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces,
java.naming.provider.url=localhost:1199
But when i get initial context and inspecting its attributes it reveals that java.naming.factory.initial changes to org.apache.naming.java.JavaURLContextFactory and all other properties remains same as in the jndi.properties file.I dont understand why this single property gets changes ? How can i prevent this and force tomcat to use property i have specified ?
I believe the JNDI properties should be vendor specific, What you trying to put is for Jboss JNDI properties, and may have been reverting to for Tomcat Specific Proerties. Although you can try to overwrite them programatically, it might not work properly.
You should put all this stuff into a Resource element in your META-INF/context.xml file, and look up that resource via a java:comp/env URL. That's what Tomcat is trying to set up here: an object factory for that namespace.
I think you should append your properties to your catalina.properties file,it's under your $tomcat_home/conf.
I developed a sample web application which will read the data from an external properties file. The properties file is in the source folder in my system and is not included inside the WAR file.
The property file is accessed like this:
Properties prop = new Properties();
//File f1 = new File("Property.properties");
prop.load(getClass().getClassLoader().getResourceAsStream("Property.properties"));
How do I access this property file externally inside the WAR file?
What changes have to be made in the code to read it in the WAR file?
I think the most versatile approach is to define a simple environment entry as described in the section EE.5.4 Simple Environment Entries of Java™ Platform, Enterprise Edition (Java EE) Specification, v5.
From the section (page 68):
A simple environment entry is a configuration parameter used to
customize an application component’s business logic. The environment
entry values may be one of the following Java types: String,
Character, Byte, Short, Integer, Long, Boolean, Double, and Float.
You may also use URL connection factory as described in the section EE.5.6.1.4 Standard Resource Manager Connection Factory Types of the specification.
The Application Component Provider must use the java.net.URL resource
manager connection factory type for obtaining URL connections.
Both require a definition of a resource reference in the deployment descriptor WEB-INF/web.xml of your web application so you can inject the value using #Resource or use JNDI API with java:comp/env as the entry point.
The benefit is that you can change the configuration of your web application without having to recompile the code as well as let you change it using an application server's administrative tools your admins are accustomed with.
In web.xml you define the resource reference.
<resource-ref>
<res-ref-name>propertiesURL</res-ref-name>
<res-type>java.net.URL</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
<resource-ref>
<res-ref-name>propertiesPath</res-ref-name>
<res-type>java.lang.String</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
Then in your code you use the following to access the values:
#Resource
String propertiesPath;
#Resource
URL propertiesURL;
With this you met the requirements of Java EE and you can use propertiesPath or propertiesURL as if they were passed as input parameters to your methods.
Now, it's time to meet expectations of WebSphere Application Server.
What you defined are logical names that need to be mapped to their administered names (an application server knows about and can provide to the application).
In WebSphere Application Server you use WebSphere Binding descriptor WEB-INF/ibm-web-bnd.xml with the following configuration:
<?xml version="1.0" encoding="UTF-8"?>
<web-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-web-bnd_1_1.xsd"
version="1.1">
<virtual-host name="default_host" />
<resource-ref name="propertyURL" binding-name="propertyURL" />
<resource-ref name="propertyURL" binding-name="propertyURL" />
</web-bnd>
When the application gets deployed WAS allows you to map these mappings to its administered resources. Use the ISC console to define values of the environment entries and map them to the application.
It has became easier with WebSphere Liberty Profile. I described the mechanism as offered by WLP in my article Using #Resource to access JNDI in WebSphere AS 8.5 Liberty Profile.
You have three options:
configure the Websphere to include the directory which contains the property file in the classpath. Don't know how to do it, but I'm sure it is possible, since our application does the same thing
include the property file in the war archive. You probably don't want to do that.
instead using the classloader to load the property file use the file api with an absolute path. I'm not completely sure WAS does allow that, but it is a bad idea anyway, because it makes your application very dependent on things that it really shouldn't care about, such as the installation path of your application.
WebSphere has two folders on the classpath, properties can be loaded from there:
Enterprise Applications > myear > Manage Modules > myjar.jar > Class loader viewer
4 - Extension - com.ibm.ws.bootstrap.ExtClassLoader
file:/projekte/IBM/WebSphere/AppServer-8.5/classes/
file:/projekte/IBM/WebSphere/AppServer-8.5/lib/
I'm going through the EJB 3.1 spec and am trying to grasp the different possible ways a JNDI call can be made.
You can do it using a SessionContext and an InitialContext (or a self-created context based on the Initial- or SessionContext).
Based on which you use the syntax differs, but I can't seem to find the logic behind it.
So my question is: when can I use what syntax to use JNDI calls within an EJB container environment?
The rest of this question just serves as illustration of my point.
For example, I believe this is always possible for a correctly injected sessioncontext or created initialcontext:
ctx.lookup(java:global[/<app-name>]/<module-name>/<bean-name>[!<fully-qualified-interface-name>])
ctx.lookup(java:comp/env ...)
// special ones like these
ctx.lookup("java:comp/UserTransaction");
ctx.lookup("java:comp/ORB");
Sometimes (only for session context?) this shorter version is possible:
ctx.lookup(<bean-name>);
What about in an embedded environment, can only global references be used?
I usually inject EJBs inside EJB container with #EJB annotation. So the JDNI look ups are done by the server at deploy time.
For example JBOSS deployment:
INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named TestBean in deployment unit subdeployment "MyEJB.jar" of deployment "MyProject.ear" are as follows:
java:global/MyProject/MyEJB/TestBean!my.project.TestBean
java:app/MyEJB/TestEJB!my.project.TestBean
java:module/TestEJB!my.project.TestBean
java:global/MyProject/MyEJB/TestEJB
java:app/MyEJB/TestBean
java:module/TestBean
Some are per EJB specification some are application server dependent.
If you have to make look ups from context I think the best way is to use java:global.
You can also find some additional info at: http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#POJOLocalEJB
jndi is a bit like a file system. You can refer to things using a relative path based on where you are in the tree (where you "cd"-ed to).
The injected session context is by default "positioned" on java:comp, so there you reference things that are available in java:comp, without the need to provide the "full path".
Note that java:comp itself is relative to a single EJB bean, or because of historical reasons to the entire Web module.
I'm not 100% sure what you mean with embedded environment, but if the code from which you are doing the JNDI lookup is not part of any of the predefined scopes (like java:module, java:app, etc) only java:global can be portably used.
I'm creating a java web application which should run on multiple application servers (jetty, tomcat, websphere, jboss). There is an optional datasource in this application. If it is configured the application will use it, otherwise some functionality in the application will be disabled.
The problem is, if I define the resource-ref in the web.xml, it will be required to be defined in the application context. If I don't define it in the web.xml, then when I try to deploy the application in websphere, there is no way to reference the datasource in the application.
Is there a way to make websphere aware of the optional datasource without always having to define it in the application context?
Don't use an "optional data source". Instead, always define the resource-ref, and add an env-entry:
#Resource(name="useDataSource")
private boolean useDataSource;
...or corresponding XML:
<env-entry>
<env-entry-name>useDataSource</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>false</env-entry-value>
</env-entry>
The value of the env-entry can be changed at deployment time.