I am working on an assignment that is already built to some extent. It is a Spring 3.0 project with Spring Integration and Spring MVC. I see that in web.xml, the is defined and the name is associated to the DispatcherServlet class. But in /web-inf/ I don't see the Dispatcher-servlet.xml
when I looked at the spring documentation, I read that the Dispatcher-servlet.xml is mandatory.
The app is working fine. The jsp is fetched and the flow is as expected.But without the Dispatcher-servlet.xml, how is it working? Any thoughts?
Thanks,
Jan.
Eg: here is my web.xml definition. Over here my dispatcherservlet name is springController-servlet.xml which is placed in the web-inf folder.
<servlet>
<servlet-name>springController</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>springController</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
Check yours and revert back. Spring requires a dispatcher servlet file.
Related
When I right click index.xhtml and go to "Run On Server" I get a 404 error.
Below I will show my web.xml, as well as some of the error messages I get. This is just a basic hello world app, nothing special yet.
My index.xhtml is in the webcontent folder.
Using eclipse luna and tomcat 8. JSF 2.2
web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
<display-name>SpecificationGeneratorDataEntryTool</display-name>
<welcome-file-list>
<welcome-file>faces/index.xhtml</welcome-file>
</welcome-file-list>
<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>/faces/*</url-pattern>
</servlet-mapping>
<context-param>
<param-name>javax.servlet.jsp.jstl.fmt.localizationContext</param-name>
<param-value>resources.application</param-value>
</context-param>
<context-param>
<description>State saving method: 'client' or 'server' (=default). See JSF Specification 2.5.2</description>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
<context-param>
<description>
This parameter tells MyFaces if javascript code should be allowed in
the rendered HTML output.
If javascript is allowed, command_link anchors will have javascript code
that submits the corresponding form.
If javascript is not allowed, the state saving info and nested parameters
will be added as url parameters.
Default is 'true'</description>
<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<description>
If true, rendered HTML code will be formatted, so that it is 'human-readable'
i.e. additional line separators and whitespace will be written, that do not
influence the HTML code.
Default is 'true'</description>
<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<description>
If true, a javascript function will be rendered that is able to restore the
former vertical scroll on every request. Convenient feature if you have pages
with long lists and you do not want the browser page to always jump to the top
if you trigger a link or button action that stays on the same page.
Default is 'false'
</description>
<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
<param-value>true</param-value>
</context-param>
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
</web-app>
Error output:
SEVERE: Exception sending context initialized event to listener instance of class org.apache.myfaces.webapp.StartupServletContextListener
java.lang.NoClassDefFoundError: org/apache/commons/digester/Digester
at org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl.<init>(DigesterFacesConfigUnmarshallerImpl.java:44)
SEVERE: Exception sending context initialized event to listener instance of class org.apache.myfaces.webapp.StartupServletContextListener
java.lang.NoClassDefFoundError: org/apache/commons/digester/Digester
SEVERE: Exception sending context destroyed event to listener instance of class org.apache.myfaces.webapp.StartupServletContextListener
java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml.
A typical config looks like this;
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:305)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
at org.apache.myfaces.context.servlet.FacesContextImplBase.getApplication(FacesContextImplBase.java:169)
at org.apache.myfaces.webapp.AbstractFacesInitializer._dispatchApplicationEvent(AbstractFacesInitializer.java:329)
at org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:364)
at org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:167)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4906)
at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5545)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:221)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:149)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1408)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1398)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
if 404 error means resource is not found that means your first welcome page is not load please check the name of servlet class in xml and please proper path in welcome-file
I was going through one of the books on JSF (JavaSever Faces - Introduction by Example) and I found the following excerpt
Prior to JSF 2.0, in order to enable the JSF servlet to translate the XHTML page, you needed to ensure that the
web.xml file contained a servlet element indicating the javax.faces.webapp.FacesServlet class and its associated
servlet-mapping URL. Since the release of JSF 2.0, if using a Servlet 3.x container, the FacesServlet is automatically
mapped for you, so there is no requirement to adjust the web.xml configuration.
I decided to try it out, but did NOT work and getting 404 error.
web.xml
<!-- Commenting this out in Glassfish server based on the book's guidelines -->
<!--
<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>/faces/*</url-pattern>
</servlet-mapping>
-->
<session-config>
<session-timeout>30</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>faces/index.xhtml</welcome-file>
</welcome-file-list>
</web-app>
Prior to moving to Glassfish 4.x I already had this working on Tomcat 8.
The weird part is as soon as I uncomment the FacesServlet mapping in deployment desriptor everything works great and I do not get 404.
Is Glassfish 4.x a Servlet 3.x container?
Am I doing something wrong or are the book guidelines incorrect?
I am following the lab manual: Getting started with IBM Connections Cloud. Last updated November 19 2014 by Jan Smolenski.
After I have setup the project and run the server (step 109) and open the mysocial.webapp url I get the message:
Error 500: javax.servlet.ServletException: Filter [SBTFilter]: Could not find required filter class - com.ibm.sbt.util.SBTFilter.class
In the console I read:
[ERROR ] SRVE0321E: The [SBTFilter] filter did not load during start up.
How can I include the sbtfilter during startup? Should I import additional libraries from the SDK or alter my configuration?
I run the samples exactly as declared in the lab manual...
There is a sample project called social.helloworld.webapp. You can look at the following web.xml
https://github.com/OpenNTF/SocialSDK/blob/master/samples/j2ee/templates/social.helloworld.webapp/src/main/webapp/WEB-INF/web.xml
Copy the Following Lines
<servlet>
<description>The service servlet handles requests from the toolkit to access external resources.</description>
<display-name>Social Business Toolkit Service Servlet</display-name>
<servlet-name>ServiceServlet</servlet-name>
<servlet-class>com.ibm.sbt.service.core.servlet.ServiceServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ServiceServlet</servlet-name>
<url-pattern>/service/*</url-pattern>
</servlet-mapping>
<servlet>
<description>This servlet initializes the specified JavaScript library for use by the Social Business Toolkit.</description>
<display-name>Social Business Toolkit Library Servlet</display-name>
<servlet-name>LibraryServlet</servlet-name>
<servlet-class>com.ibm.sbt.jslibrary.servlet.LibraryServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>LibraryServlet</servlet-name>
<url-pattern>/library/*</url-pattern>
</servlet-mapping>
<filter>
<description>This filter is responsible for creating the toolkit application and context objects for every servlet within this web application.</description>
<display-name>Social Business Toolkit Filter</display-name>
<filter-name>SBTFilter</filter-name>
<filter-class>com.ibm.sbt.util.SBTFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>SBTFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<resource-ref>
<description>Reference to a URL resource which points to the managed bean configuration for the Social Business Toolkit.</description>
<res-ref-name>url/ibmsbt-managedbeansxml</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>
<description>Reference to a URL resource which points to the configuration properties for the Social Business Toolkit.</description>
<res-ref-name>url/ibmsbt-sbtproperties</res-ref-name>
<res-type>java.net.URL</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
and then restart your webapp
you can also make sure that the jar files exist.
Another good reference is... https://github.com/OpenNTF/SocialSDK/wiki/Building-your-first-social-enabled-jsp
I have an Icefaces 3.x + JSF 2.1 app where I tried to integrate upload file solution from here but I receive
14:31:24,506 WARN
[org.apache.myfaces.custom.fileupload.HtmlFileUploadRenderer]
(http-localhost-127.0.0.1-8080-3) t:inputFileUpload requires
ExtensionsFilter or TomahawkFacesContextFactory configured to handle
multipart file upload, and any of them has been detected. Please read
the instructions on
http://myfaces.apache.org/tomahawk/extensionsFilter.html for more
information about how to setup your environment correctly. Please be
sure ExtensionsFilter is the top most filter if you are using multiple
jsf libraries. 14:31:24,507 WARN
[org.apache.myfaces.custom.fileupload.HtmlFileUploadRenderer]
(http-localhost-127.0.0.1-8080-3) t:inputFileUpload requires the
current request be intercepted by the filter in order to handle forms
with multipart encode type. ExtensionsFilter was initialized but the
current request was not intercepted. Please add a filter-mapping entry
to intercept jsf page requests.
which is pretty strange because I added:
<filter>
<filter-name>MyFacesExtensionsFilter</filter-name>
<filter-class>org.apache.myfaces.webapp.filter.ExtensionsFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>MyFacesExtensionsFilter</filter-name>
<servlet-name>Faces Servlet</servlet-name>
</filter-mapping>
into my web.xml but still the uploaded file is null.
Any clue to what I do wrong?
I can't reach XSD schema. Here is my configuration:
web.xml
<servlet>
<servlet-name>spring-ws</servlet-name>
<servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>
<init-param>
<param-name>transformWsdlLocations</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>spring-ws</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
spring-ws-servlet.xml
<sws:annotation-driven/>
<context:component-scan base-package="example.ws.endpoint"/>
<sws:dynamic-wsdl id="boo"
portTypeName="BooResource"
locationUri="/services/">
<sws:xsd location="classpath:example/ws/schema/Boo.xsd"/>
</sws:dynamic-wsdl>
WSDL is accessible on [http://localhost:port/spring-ws-server-0.1-SNAPSHOT/services/boo.wsdl], but how can I expose XSD and what will be the URL?
I've been able to expose my XSD's without using Spring-MVC for it by defining something like this in my #Configuration class:
private ClassPathResource messagesXsdResource = new ClassPathResource("messages.xsd");
#Bean
public SimpleXsdSchema messages() {
return new SimpleXsdSchema(messagesXsdResource);
}
You should take a look at this question as well, that explains how to do this in XML.
I'm afraid this is not possible, at least not automatically like your WSDLs are exposed. Spring WS doesn't intend to make your XSDs available like it does with the static and generated WSDLs. Of course, you can make your XSDs available through a simple servlet or through MVC (if you're using MVC as well).
If you're using Spring Boot, whatever you put under the public folder which you can create under resources, will be publicly available.
You can put your xsd there and point your wsdl to that definition:
<xsd:schema>
<xsd:import namespace="http://jaxws.com.your.ns" schemaLocation="/your.xsd"/>
</xsd:schema>
Now this will make your xsd available at http://localhost:8080/your.xsd