We're using Jetty 6.x, and Maven-2.
Anybody knows how to configure the default document?
I mean - there's a default that serves /index.html or any of it's equivalents when accessing the application root (browse to /).
And there should be a settings to control that.
(there is in tomcat and in IIS for example...)
So 1 - how do I tell it to Jetty?
I know the Jetty guys are proud in letting almost everything to be configured - there has to be a way to do that, it's just a problem of a poor documentation, that's what my instinct tells me.
And 2 - how do I do that using Maven plugin ?
This is actually a "bonus" question, if you only tell me how to do it with Jetty - I hope'll find eventually how to do it with Maven too. But in case anybody knows - it will be a great help :)
Ok, I found it.
It has nothing to do with Jetty or Maven, although I'm sure that Jetty can provide it's own overrider configuration or defaults or something.
It was hard to find because they don't call it default document, but welcome-files.
It's a part of the JSP Servlet deffinitions, and is working with the file: /META-INF/web.xml
And here's what needs to be inside
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" 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-app_2_5.xsd">
<welcome-file-list>
<welcome-file>customDefaultDocument.html</welcome-file>
</welcome-file-list>
</web-app>
Related
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.
Hi I'm putting together a fairly basic app using spring 4 MVC. I am using config java classes rather than xml config. I'm pretty new to this but all is slowly moving forward well. I have hit a problem though in that I wanted to include a header into all the jsp page views.
So I have included the include-prelude into my web.xml file
<?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">
<display-name>Web Application</display-name>
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<include-prelude>/WEB-INF/views/include/header.jspf</include-prelude> </jsp-property-group>
</jsp-config>
</web-app>
This is working if I add a dummy jsp file into the webapp folder (I'm using maven and eclipse) and access it directly. However it is not working for the JSP's accessed via spring MVC. It is working in a similar application I inherited which has the spring bootstrap config in xml files rather than java classes. I won't have millions of pages so I guess I can use a jsp:include but...
Can anyone tell me how I should go about getting the header.jspf picked up ? Ideally I'd like to keep the config in java classes but perhaps I have to use the xml bootstrapping ?
Also as a supplementary question which is not really what I'm asking so please ignore if it's against all the rules (!) when I've googled this a bit I keep reading that JSP's are no longer the way to go for views. I'm writing a fairly basic intranet forms app (I've recently switched from microsoft technologies so apologies if you don't like that terminology!). Do you think I should be using somethign other than JSPs & jspf's
Thanks
In case you are wondering what is the answer to the OP'S question, the answer is to simply add this to your web.xml tag (if you are using Tomcat instead of GlassFish):
xmlns:my="http://jakarta.apache.org/tomcat/jsp2-example-taglib"
So your web.xml should look like this at the beginning:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
version="3.0"
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-app_3_0.xsd"
xmlns:my="http://jakarta.apache.org/tomcat/jsp2-example-taglib">
I hope this could helped you ;)
You can use jsp.There is no problem with that the only thing you need to change is instead of giving url-mapping like .jsp use url mapping .abc, here you can use abc,xyz,ani,spring,do etc anything rather then jsp.So it will work fine .
If you use *.jsp in url mapping and use jsp as view it will give you 404 everytime.
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
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">
Following an issue reported on this question, a solution was found:
req.setAttribute("org.apache.catalina.ASYNC_SUPPORTED", true);
This seems a bit strange and is not really 'portable' code (it won't hurt, but...). It seems specific to Tomcat 7. I am using Tomcat 7.0.14 as delivered by NetBeans 7.0.1.
I could not find documentation indicating it is necessary to enable async request processing in servlet 3.0 with a catalina attribute. I could not find documentation indicating something special was necessary at the Tomcat configuration level too.
Is there a way to avoid having to set ASYNC_SUPPORTED=true in each request to enable async servlet 3.0 processing in Tomcat 7?
A couple of things to check first:
Make sure any filters that operate on the request also support async (as addressed in one of the answers to the question you referenced).
Make sure you're using a Servlet 3.0 web.xml - for example:
<web-app 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-app_3_0.xsd"
version="3.0"
metadata-complete="true">
Try upgrading.
Bug 53623 fixed in 7.0.30.
"Enable remaining valves for Servlet 3 asynchronous processing support." (fixed in 7.0.16)
Check the Tomcat 7 ChangeLog for complete details.
Also, if you want to use async, then you'll need to make sure that all of the filters and valves in the chain (as well as the servlet, of course) all support async. This is likely the problem in the original question, as well as with your case, here.
I found that org.apache.catalina.ASYNC_SUPPORTED=true is only needed when you from one normal-servlet/jsp (internally) forward to an async-servlet!
Example: In my index.jsp, I embed <jsp:forward page="/path/AsyncServlet" />
I promise the AsyncServlet works fine on both Tomcat7 and Glassfish3, when I directly trigger it from browser!
However when I trigger it by index.jsp:
Tomcat7 reports 500 for "Not supported"
Glassfish3 reports 500 for "Request is within the scope of a filter or servlet that does not support asynchronous operations"
If I embed <% request.setAttribute("org.apache.catalina.ASYNC_SUPPORTED", true); %> before <jsp:forward> in index.jsp, Tomcat7 goes OK, but Glassfish3 still is BAD!
So I found a solution for both Tomcat7 and Glassfish3 (without SYNC_SUPPORTED!):
Just EXACTLY attach followings in web.xml:
<servlet>
<servlet-name>indexPage</servlet-name>
<jsp-file>/index.jsp</jsp-file>
<async-supported>true</async-supported>
</servlet>
<servlet-mapping>
<servlet-name>indexPage</servlet-name>
<url-pattern>/index.jsp</url-pattern>
</servlet-mapping>
Conclusion (for me):
You can NOT forward from a normal-servlet/jsp/filter to an async-one! Since the async-request feature MUST be preset!
So the common solution for a servlet/jsp/filter which needs to forward to an async-servlet is:
Use <servlet>/<async-supported>true or #WebServlet(asyncSupported = true) for a pre-processed servlet;
Use <servlet>/<async-supported>true for a pre-processed jsp
Use <filter>/<async-supported>true or #WebFilter(asyncSupported = true) for a pre-processed filter;
Hope this may help a little bit!