We Keep Coding

Spring Boot Datasource JNDI lookup on Websphere 9

I have a Spring Boot application that I usually deploy on a Tomcat server. Now I want to be able to also deploy it on Websphere 9, though it will still be deployed on the usual Tomcat server most of the time. I packaged the app as a war and deployed it on Websphere through the admin interface, then ran the application. And as pointed out in many other posts, it did not work because JNDI lookup does not work the same way. I tried solutions offered here and there, but nothing worked.
My datasource is defined in Websphere with name jdbc/foobar. My lookup is done in my Spring Boot app with:
JndiDataSourceLookup dataSourceLookup = new JndiDataSourceLookup();
DataSource ds = dataSourceLookup.getDataSource("java:comp/env/jdbc/foobar");
This works on Tomcat but does not on Websphere. Many answers on other SO posts about this say that for Websphere, one must lookup "jdbc/foobar" without the prefix (for instance here in the answer's comments), which is true (I could get it to work), but I want to have code that remains compatible with the usual deployment on tomcat.
As a side note, the getDataSource method automatically adds the prefix if it is absent, which means I needed to do this instead:
JndiDataSourceLookup dataSourceLookup = new JndiDataSourceLookup();
dataSourceLookup.getJndiTemplate().getContext().lookup("jdbc/foobar");
This still is useful because, since it worked well, it proved that my problem is not a wrong datasource definition at server side.
Since I want my code to remain the same tomcat-compatible code, I kept the "java:comp/env/jdbc/foobar" lookup and I looked into the answers advising to add some configuration, most notably this one. I located the ibm-web-bnd.xml file, which is created by Websphere at deployement time and put in the WEB-INF folder. I added the advised resource-ref tag there:
<?xml version="1.0" encoding="UTF-8"?>
<web-bnd xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://websphere.ibm.com/xml/ns/javaee"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-web-bnd_1_0.xsd" version="1.0">
<virtual-host name="default_host"/>
<resource-ref name="jdbc/foobar" binding-name="jdbc/foobar" />
</web-bnd>
Then, since I don't have a web.xml in my war, I tried the #Resource trick:
#Component
#Resource(name = "jdbc/foobar",type = javax.sql.DataSource.class)
public class MyServlet extends HttpServlet {
I could verify the servlet is loaded correctly but the Resource annotation does no seem to do the trick. Then I noticed a web.xml is also created by Websphere beside the ibm-web-bnd.xml file, so I supposed I might give it a try and I added the resource-ref tag inside (the rest was already here, added by Websphere):
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<env-entry>
<env-entry-name>logback/context-name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>main</env-entry-value>
</env-entry>
<listener>
<listener-class>ch.qos.logback.classic.selector.servlet.ContextDetachingSCL</listener-class>
</listener>
<session-config>
<session-timeout>15</session-timeout>
</session-config>
<resource-ref>
<description />
<res-ref-name>jdbc/foobar</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</web-app>
This still did not work. I also noticed that Websphere created another file named web_merged.xml, which seems to merge the automatically created web.xml with the real one (which in my case does not exist). I tried to add the same code shown above to this file too, but it did not work better.
Now, I am out of clue. Does someone have any other idea, or maybe noticed an obvious mistake I made?

What you tried in the bindings file looks like it should have worked, assuming that you are performing the lookup from within the same web module in which you specified the binding (because it is java:comp scoped).
Even so, you ought to be able to do this in a completely standard way without a bindings file at all (where it can be difficult to get all of the syntax correct), by just using the #Resource annotation alone,
#Resource(name = "java:comp/env/jdbc/foobar", lookup = "jdbc/foobar", type = javax.sql.DataSource.class)
I'd recommend getting rid of the extra bindings/deployment descriptor that you were experimenting with and try with just the annotation, at least to start with. If it turns out that you aren't in the same module, you could use java:app (if in the same app) or otherwise java:global instead of java:comp, which you would need to update in both places.

Different session IDs for JAX-RS resources

I faced a very strange behavior with WildFly 8.x (tested with 8.1 and 8.0 also). If I deploy my WAR as ROOT (set the '/' as context-root in jboss-web.xml) my JAX-RS resource classes will have different session IDs (each resource class will have a unique session id). But in fact, if I set anything else other than '/' as the context-root everything works as I expected originally (every JAX-RS resource class share the same session).
I know that REST services are stateless and I don't have to worry about sessions but I'm so curious why it behaves like that. Does anyone have any ideas?
Thanks!
Here's a sample minimal project where you can reproduce this issue: https://github.com/aberkes/cdi-sessionscoped-bean-demo

The idea is that by default if you deploy to ROOT, jboss doesn't use a fixed cookie path parameter. This is made for the case, when you have other applications running in different sub-folders and requiring their own independent sessions.
To change this behaviour, you may use the
<session-config>
<cookie-config>
<path>/</path>
</cookie-config>
</session-config>
parameter in your web.xml. Then all jsessions will be bound to the root path.

WebService is not "visible" in WebLogic 10.3

I am currently trying to let my application provide a webservice.
The application uses spring and is running under a Weblogic 10.3 instance.
I built the webservice following the "contract first" approach.
So what I basicaly have is a generated WS-Interface, my implementation of that interface, a web.xml defining the servlet-bindings and a sun-jaxws.xml defining the endpoint.
(more or less similar to this: http://www.mkyong.com/webservices/jax-ws/deploy-jax-ws-web-services-on-tomcat/).
Now, after deploying my application to weblogic, actualy everything is workign fine.
I can type the URL of the WebService into my browser, I see the WSDL, I can call it's methods.
If the weren't a small cosmetic fact:
In the deployments overview of WL when I click on the deployment, it shows me a list of WebServices...which is empty. So my webservice is NOT listed there.
So, can anyone tell me, what I have to do to get the webservice to show up there?

Though it's not really essential to have a webservice descriptor for JAX-WS, Weblogic at times fails to identify the WebServices(was not able to find a reason for this)
Below is what I did to get it working. Add the WebService implementation class as a Servlet in web.xml
<?xml version='1.0' encoding='UTF-8'?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.4" id="WebApp_ID">
<display-name>MyWebService</display-name>
<servlet>
<servlet-name>serviceServlet</servlet-name>
<servlet-class>com.aneesh.WebServiceImpl</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>serviceServlet</servlet-name>
<url-pattern>/Service</url-pattern>
</servlet-mapping>
</web-app>
and add the webservice descriptor (webservices.xml)
<?xml version='1.0' encoding='UTF-8'?>
<webservices xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1">
<webservice-description>
<webservice-description-name>MyWebService</webservice-description-name>
<port-component>
<port-component-name>MyWebServiceSoapPort</port-component-name>
<wsdl-port xmlns:an="http://www.aneesh.com/service">an:MyWebServiceSoapPort</wsdl-port>
<service-endpoint-interface>com.aneesh.WebService</service-endpoint-interface>
<service-impl-bean>
<servlet-link>serviceServlet</servlet-link>
</service-impl-bean>
</port-component>
</webservice-description>
</webservices>

Depending on the developer that created the Web Service, deployment descriptors such as webservices.xml and weblogic-webservices.xml were added to the application. Descriptors are used for configuration, overriding default settings, and adding metadata. For Web Services this can be the endpoint, port configuration, linkage of the Web Service to EJB components, and so on. When deployed, the WSDL location of Web Services is listed in the WebLogic Console and the WSDL can be retrieved at runtime.
From the Trenches 2 | Patching OSB and SOA Suite to PS5
See also:
WebLogic Web Service Deployment Descriptor Element Reference
Developing Spring-Based Applications for Oracle WebLogic Server

JSF2.0 - *.xhtml pages give 404-NotFound but *.jsp work okay?

I have Weblogic 10.3.5 installed. I deployed the JSF 2.0 war on the server. In my WebContent folder, I have *.xhtml and *.jsp files, which contain JSF2.0 xhtml and pure JSP code, respectively. When I navigate to http://localhost:7001/MyApp/NewFile123.xhtml, I get a 404 Not found error page. (Nothing informative on the Eclipse console). But http://localhost:7001/MyApp/NewFile.jsp works well and does what it's supposed to do.
I am not mixing JSF and JSP but just wanted to see if JSP is gonna work. I have the appropriate servlet-mapping for the XHTML files.
I also have these on my classpath:
glassfish.el_1.0.0.0_2-2.jar
glassfish.jsf_1.0.0.0_2-1-5.jar
glassfish.jstl_1.2.0.2.jar
javax.servlet_1.0.0.0_2-5.jar
Another interesting thing, when I try to edit the *.xhtml files, the auto-complete doesn't work. (i.e it won't autocomplete <h:outp. It used to when I was using Weblogic 12.1 which has JSF2.0 out of the box.
Edit: Here is the relevant part of web.xml
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
So why do I get a 404 when I try to navigate to a JSF page? Any suggestions?

I also have these on my classpath:
glassfish.el_1.0.0.0_2-2.jar
glassfish.jsf_1.0.0.0_2-1-5.jar
glassfish.jstl_1.2.0.2.jar
javax.servlet_1.0.0.0_2-5.jar
Remove all those container-specific libraries from your /WEB-INF/lib. They do not belong there at all, the container already ships with them. Your /WEB-INF/lib should contain only the webapp-specific libraries which are not shipped with the container.
Your problem is most likely caused by the fact that Weblogic 1.0.3.5 is a Servlet 2.5 container which already ships with JSF 2.0, but that you're supplying a JSF 2.1 library which requires Servlet 3.0. I don't use Weblogic, but I've read that 1.0.3.x requires some specific steps to get JSF 2.0 to work, see also this blog. Here's an extract of relevance:
Download and install one of the latest Oracle WebLogic Server 11g Rel 1 (10.3.3) Installers from OTN. (Give the ZIP Installer a try. Aweseome lightweight!)
Create a new sample domain (call it whatever you want) and start the admin server
Open the administration console (http://localhost:7001/console/)
deploy the JSF 2.0 library (Deployments - Install - wlserver_10.3\common\deployable-libraries\jsf-2.0.war
Find your favorite JSF 2.0 sample (I'll take the guessNumber thing from the mojarra-2.0.2 distribution)
Add a weblogic.xml file to the WEB-INF/ folder with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app>
<library-ref>
<library-name>jsf</library-name>
<specification-version>2.0</specification-version>
<implementation-version>1.0.0.0_2-0-2</implementation-version>
<exact-match>true</exact-match>
</library-ref>
</weblogic-web-app>
Update as per the comments:
I now suspect that it may be because of the project settings. I created a Dynamic Web Project and chose JSF 1.2. On the next step, where it asked me for the JSF specification and implementation, I pointed him to those glassfish jsf2 jars. The default was 1.2. Maybe I shouldn't have done that?
That might have generated a JSF 1.2 compliant faces-config.xml which would force JSF 2.0 to run in JSF 1.2 modus. You need to redeclare the <faces-config> root declaration to comply JSF 2.0.
<faces-config
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">

How do you set crossContext and enptySessionPath in Jboss7?

I am trying to migrate the deployment of some applications from tomcat 6 to jboss-as 7.
A single sign-on mechanism has been implemented for these projects, which, in order to work, needs to have crossContext="true" set in the tomcat context.xml file and emptySessionPath="true" in the connector configuration found within server.xml.
How can these settings be mimicked in jboss7? I know that jboss uses a modified tomcat as a servlet container, but I have been unable to find any of these settings.

Found this: http://community.jboss.org/message/617186
Not sure if it works though...

Servlet 3.0 specification supported by JBoss 7.1 allows specification of session cookie path in web.xml. Just put this fragment to all of your wars whose context you want to be shared:
<session-config>
<cookie-config>
<path>/</path>
</cookie-config>
</session-config>