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.
Related
When I am trying to deploy my war file from tomcat to websphere I am getting the following error.
1)org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.bus.spring.SpringBus]: Constructor threw exception; nested exception is org.apache.cxf.bus.extension.ExtensionException: Could not load extension class org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl.
2)org.apache.cxf.bus.extension.ExtensionException: Could not load extension class org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl.
3)java.lang.IncompatibleClassChangeError: org.apache.neethi.AssertionBuilderFactory
I tried by changing the class loader from parent first to parent last(Vice-Versa).But still I am getting same error
Help me out.
There are potentially several issues with your app:
You probably include Java EE jars in your application - like jee.jar, servlet.jar etc - please remove all these jars from WEB-INF/lib directory.
It looks like you are bundling your own web services engine (CXF) inside your application. tWAS provides its own web services engine. So you either need to migrate to the provided or disable tWAS one. Check the Using a third-party JAX-WS web services engine page. You will need to set DisableIBMJAXWSEngine property and configure module classloader for your war to parent last.
I still would recommend migrating to Liberty if possible, instead of traditional.
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.
In Tomcat, session manager attribute can be given in the context.xml of server.So in JBoss where it can be given - standalone.xml ? Does it support Context descriptor ?
Thanks in Advance
Try this,
create an implementation of the org.jboss.as.clustering.web.DistributedCacheManagerFactory interface (and all dependent interfaces)
create a module that defines a META-INF/services/org.jboss.as.clustering.web.DistributedCacheManagerFactory file that points to your implementation
replace the default implementation (org.jboss.as.clustering.web.infinispan) in $JBOSS_HOME/modules/org/jboss/as/clustering/web/spi/main/module.xml with your custom module.
There are now 2 msm jars you have to put into lib: the core msm jar and the jboss specific one:
http://dl.dropbox.com/u/1439289/msm-all-memcached-session-manager-1.5.0-SNAPSHOT.jar
http://dl.dropbox.com/u/1439289/msm-all-memcached-session-manager-jbossweb2-1.5.0-SNAPSHOT.jar
source links look this and this
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
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.