While working with an EJB application, why do we require an extra deployment descriptor such as jBoss.xml to configure the JNDI name? Can't we do the same in the ejb-jar.xml file itself?
As it seems from your comment you're interested in setting the remote EJB view JNDI name.
The point is - the JNDI name within the server is defined using Java EE 6 portable JNDI names (every container is required to bind EJBs under those names.)
However, the remote (exported) JNDI name is not specified by any document. This is one of the things that confused me some time ago.
It occurs that either you will use ACC (Application Client Container) or obey to container-specific configuration. This means that there is no portable name of telling the container to expose remote EJB view under specified JNDI names.
Further reading:
http://java.net/projects/ejb-spec/lists/users/archive/2012-11/message/13
http://java.net/projects/ejb-spec/lists/users/archive/2013-01/message/41
Related
I am looking for a solution to the problem, which is that having an external Tomcat server with several different applications (war),
I would like to use application Spring Profile (dev, prod) to choose application.properties for a given profile.
To avoid keeping the database configuration in the git repository, I didn't store in the application
application.properties, but I kept them in the $catalina.base directory, where in common.loader
I indicated the path to this directory. This worked until I started deploying several different applications. Then each of them began to use
from the same datasource. One solution is to keep the application.properties in Jenkins and directly in Jobie indicating which one to use,
but I am not sure if this is a good solution.
Option 1: Create a separate instance of tomcat (using same tomcat binary) and place application.properties in instance's classpath. As classpath is separate for every instance, applications don't refer to same application.properties file. Refer to this article to see how to create multiple instances on same tomcat server.
Option 2: Create JNDI datasource on tomcat server and use it in your application to access database. This way, should you choose to, same datasource can be shared across different related applications and/or modules. For more information on how to create JNDI datasource in Tomcat, refer to this link
I have a problem with jboss 7 config on a spring project. When the server starts some ejbs should initialize in a context xml file, and everything work fine if i do like below.
bean property name="jndi" value="java:global/APP-NAME/MODULE-NAME!Classpath"
but i dont want to specify the appname because i have multiple instances of the application and they have different names. I have tested to use java:app, java:module but i need to go with java:global due to access. The modulename is no probelm, it is same on all instances.
My app is deployed in a war file and needs the appname when i do jndi lookup.
Is there a way to get the appname?
I have found a solution. In spring context im using my own LocalStatelessSessionProxyFactoryBean and override setJndiName method and get the module name from initialContext.lookup("java:module/ModuleName") and set the jndi name.
Everything works fine.
It seems that Liberty uses the default JNDI namespace. I've been using it, and it works fine.
However, I have a utility JAR that I'd like to use (I cannot change it). This external jar does a lookup for a JNDI name like this:
"java:comp/env/jdbc/MAINDB"
Is there a way to declare this name in my application, so that I can use this JAR?
That is a resource ref lookup. Assuming you are in an EE Web or EJB context when you call that code you can simply define a resource-ref in the web.xml or ejb-jar.xml for the calling web or ejb module.
I need to setup a URL resource in WebSphere and is following this tutorial. However, the tutorial requires the modification of WebSphere's web.xml and ibm-web-bnd.xml using WebSphere Studio. I don't have a WebSphere Studio so I need to modify those files manually using a text editor. I tried to "search" for the 2 files but the "search results" are so many that I don't know which one is the right file.
Where can I find the 2 files? Also what value do I need to set for the resource-ref's id? I notice that WebSphere Studio doesn't have any text field for setting the resource-ref's but it has a value on its code view.
Thank you!
web.xml is a standard JavaEE file and its structure is well-documented in the Servlet specification. In web.xml, you declare the URL as it is known within your local JNDI namespace (java:comp/env).
web.xml should be located inside WEB-INF, underneath your WAR project structure. If you are using an IDE (such as Eclipse) to create Web projects, this file should already be created for you (unless you use Servlet Specification 2.5 and up - Servlet Specification 2.5 is included with JavaEE 5.0 - where deployment descriptors are optional).
ibm-web-bnd.xml is a WebSphere-specific file. It contains the binding of declared artifacts (such as a URL definition) into a real artifacts. You should refer to IBM's documentation in order to figure out the format of that file.
The ibm-web-bnd.xml file should be located in the same directory as web.xml.
The id attribute of resource-ref can be set to any value you like, as long as it is cross-referenced by a matching id attribute inside ibm-web-bnd.xml. That's how WebSphere can correlate definitions in ibm-web-bnd.xml to definitions in web.xml. The random string you see in the tutorial are created by RAD or WSAD; you can place any identifier there.
EDIT (added instructions)
In a nutshell, the process is this:
In web.xml, you define the local JNDI name. That would be the name by which your Java code is referring to the URL. For example, myWebsiteUrl. Your code will have to perform a JNDI lookup on java:comp/env/myWebsiteUrl. The definition is along these lines:
<resource-env-ref>
<resource-env-ref-name>myWebsiteUrl</resource-env-ref-name>
<resource-env-ref-type>java.net.URL</resource-env-ref-type>
</resource-env-ref>
In WebSphere itself, add a URL definition. The key there is the JNDI name in WebSphere's JNDI tree by which the URL will be known. You can set any value there, although it is recommended (by convention) that you prefix it with url/. For example: url/test.
In ibm-web-bnd.xml, you need to bind myWebsiteUrl (looked-up by your application) to url/test (which is the JNDI name by which WebSphere knows the URL). The definition will be along the lines of:
<resource-env-ref name="myWebsiteUrl" binding-name="url/test"/>
Step 3 is not required. If ibm-web-bnd.xml doesn't exist at deployment time, then the GUI-based deployment flow (used when you deploy applications through the WAS administration console) will prompt you for the binding values. (If you are deploying using scripting, you can still omit the ibm-web-bnd.xml file as long as you specify the bindings in a different way, but that's beyond the scope of this answer. Read the IBM documentation about strategy files and AdminApp.installApplication)
Note: as long as you use JavaEE 5.0 and up, you don't need the id attribute in the definitions. The article you're reading, by the way, is extremely outdated.
Environment:
Tomcat 7
JNDI
Spring-MyBatis
No JTA - commons pooling only
Problem: Can't get the connection pooling to work as advertised. I can't find a single example of this that doesn't use a stand-alone Transaction manager or that doesn't put all the settings in the war, which makes JNDI pointless. I'm told that JTA is overkill for this application and that we should stick with commons pooling. That makes sense but I don't see a way to configure pooling, if we do it that way.
So... how do I configure connection pooling without putting the settings in the war file AND without using a stand-alone transaction manager? Can this be done without a full Java EE Application Server? We are just moving to Tomcat from another product which actually is full Java EE, so I am thinking this may be a Container vrs. Application server issue.
The weird part is that we can and have used JNDI but the pooling is definitely wrong.
Here is one example that probably works but why bother with JNDI if the settings are going to be in META-INF/context.xml?:
MyBatis JNDI Example
Even with context.xml, it's still a container level setting. But, it's a convenient way of deploying everything in a singe unit rather than having to create the connection pool before you deploy the WAR file.
JNDI is meant to keep your application configuration generic. If you take your WAR and deploy it in WebSphere, for example, it will ignore the context.xml file. But WebSphere will see that you have a JDNI resource-ref in your web.xml and walk you through creating the data source. Same idea as Tomcat, just a different way of doing it.
If you are 100% sure that this application will only run in Tomcat then you don't have to use JNDI. But, it will save you trouble later if you do move to another container.