I've recently setup a new Weblogic 12c environment. On deploying an application that I know works in Weblogic 11g I get the error "The url-pattern /resources/* in web application is mapped to multiple Servlets."
The mapping it's referring to is in the web.xml inside the application.ear that's being deployed, but it's only mapped once:
<servlet-mapping>
<servlet-name>velocity</servlet-name>
<url-pattern>/resources/*</url-pattern>
</servlet-mapping>
The project doesn't contain any other references to the url pattern /resources/*, can someone explain where the duplicated mapping is coming from and how I can work around it?
The closest issue I could find is this: https://bugster.forgerock.org/jira/si/jira.issueviews:issue-html/OPENAM-7947/OPENAM-7947.html, which has been marked as unreproducible.
Full stack trace from deployment:
<Error> <Deployer> <BEA-149205> <Failed to initialize the application "<application_name>" due to error weblogic.application.ModuleException: weblogic.management.DeploymentException: [HTTP:101401]The url-pa
ttern /resources/* in web application <application_name> is mapped to multiple Servlets.
weblogic.application.ModuleException: weblogic.management.DeploymentException: [HTTP:101401]The url-pattern /resources/* in web application <application_name> is mapped to multiple Servlets.
at weblogic.application.internal.ExtensibleModuleWrapper.prepare(ExtensibleModuleWrapper.java:114)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:100)
at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:192)
at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:187)
at weblogic.application.utils.StateMachineDriver$ParallelChange.run(StateMachineDriver.java:83)
at weblogic.application.utils.StateMachineDriver.nextStateInParallel(StateMachineDriver.java:144)
at weblogic.application.internal.flow.ModuleStateDriver.parallelPrepare(ModuleStateDriver.java:46)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:75)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:55)
at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:731)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:243)
at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:66)
at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:65)
at weblogic.deploy.internal.targetserver.AppDeployment.prepare(AppDeployment.java:158)
at weblogic.management.deploy.internal.DeploymentAdapter$1.doPrepare(DeploymentAdapter.java:41)
at weblogic.management.deploy.internal.DeploymentAdapter.prepare(DeploymentAdapter.java:193)
at weblogic.management.deploy.internal.AppTransition$1.transitionApp(AppTransition.java:31)
at weblogic.management.deploy.internal.ConfiguredDeployments$2.doItem(ConfiguredDeployments.java:684)
at weblogic.management.deploy.internal.parallel.BucketInvoker.invoke(BucketInvoker.java:138)
at weblogic.management.deploy.internal.ConfiguredDeployments.transitionAppsParallel(ConfiguredDeployments.java:692)
at weblogic.management.deploy.internal.ConfiguredDeployments.prepare(ConfiguredDeployments.java:322)
at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:202)
at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:207)
at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:129)
at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:76)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1262)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:332)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:374)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1213)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1144)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:666)
at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:640)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:406)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)
If you use web annotations in java code, you don't have to declare the servlet in the web.xml file any more.
You can try by removing the corresponding "servlet" and "servlet-mapping" tags in web.xml
It seems that WebLogic 12.1.3 can deal with double declaration (inline annotation & xml) but not anymore in WebLogic 12.2.
I had this error with #webservice annotation when I specified the "serviceName" parameter and when I declared the servlet in web.xml file with the same value.
The issue doesn't exist in version 12.1.3 (which happened to be the version we were meant to be upgrading to).
Weblogic as of version 12.2.1.3 automatically registers a JAX-RS servlet to the path /resources/* in certain scenarios (e.g. some dependency like jackson-jaxrs-json-provider "requests" it via annotation/spi/moduleinfo). But if this path is already registered by another service the mentioned error is thrown.
There are 3 possible solutions one can try:
In our case the issue was coming from classpath scanning for web services components, and finding annotated services in the webservices-rt jar. That scanning needed to be switched off.
Setting the metadata-complete attribute to true in the web.xml descriptor if your Web application does not have any annotations and if you have the version set to 2.5 or higher to avoid unnecessary scanning of the Web applications classes for annotations. E.g.
<?xml version="1.0" encoding="UTF-8"?>
<web-app 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_4_0.xsd"
version="4.0"
metadata-complete="true">
<servlet>
<servlet-name>sample</servlet-name>
<servlet-class>Sample</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>sample</servlet-name>
<url-pattern>/sample</url-pattern>
</servlet-mapping>
</web-app>
Alternatively, you can turn off annotation processing and DI for all the Web applications by setting -Dweblogic.servlet.DIDisabled=true flag when starting WebLogic Server.
Registering another path for jersey in the web.xml to e.g. /jersey/*
<servlet>
<servlet-name>Jersey Web Application</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Jersey Web Application</servlet-name>
<url-pattern>/jersey/*</url-pattern>
</servlet-mapping>
Try removing the FATP jars which were added after 12.2 upgrade. This worked for me.
I have upgraded my Servlet from 2.4 to 3.0 and deployed my application on Websphere 8.5.5.8. Application Server starts properly.
When I try to access my home.jsp page in browser it throws:
Controller Main Error OG1000SRVE0190E: File not found: /servlet/com.platform7.affina.operations.servlet.ValidateLoginUser
When I try to debug, code hits my Main Controller Servlet (which is in same package) but inside Controller servlet class I am calling:
this.getServletContext().getRequestDispatcher("Servlet/com.platform7.affina.operations.servlet.ValidateLoginUser").forward(request, response);
Which throws:
FileNotFoundException for Servlet/com.platform7.affina.operations.servlet.ValidateLoginUser.
But ValidateLoginUser is in the same package and classes folder location!
Folder structure:
\NEED4SPEEDCell02\operations_1.ear\OperationsWeb.war\WEB-INF\classes\com\platform7\affina\operations\servlet
ControllerMain.class and ValidateLoginUser.class are in same servlet package.
my Web.xml file:
<servlet>
<servlet-name>servletMain</servlet-name>
<servlet-class>com.platform7.affina.operations.servlet.ControllerMain</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>servletMain</servlet-name>
<url-pattern>/controllerMain</url-pattern>
</servlet-mapping>
So when I access my URL: it hits ControllerMain.class but inside this class I am calling another servlet which is not part of web.xml but is located in same package of ControllerMain.class.
When I print realpath: this.getServletContext().getRealPath("/"));
I get:
C:\WebSphere858\AppServer\profiles\AppSrv01\installedApps\NEED4SPEEDCell02\operations_1.ear\OperationsWeb.war
I tried using getNamedDispatcher(..) too but throws: null.
Same code works fine on Websphere 7 and even works on Websphere 8.5.5.5
Due to security reasons the default setting for com.ibm.ws.webcontainer.disallowServeServletsByClassname property has been changed.
Please Note:This APAR has changed the default value of the
WebContainer custom property
com.ibm.ws.webcontainer.disallowServeServletsByClassname from false to
true so that no security threat could occur. Prior to this change, it
was up to the developer to remember to change the custom property to
true before deploying into production.
Property Name:
com.ibm.ws.webcontainer.disallowServeServletsByClassname Description:
If set to true, disallows the use of serveServletsByClassnameEnabled
at the application server level, overriding any setting of
serveServletsByClassnameEnabled at the application level. This
property affects all applications. Values: true(default)/false
You will need to add that custom property to the Web Container and set it to false for serving servlets by class name.
But as BalusC suggested, you should add your servlet to web.xml in the form:
<servlet>
<servlet-name>servletMain</servlet-name>
<servlet-class>com.platform7.affina.operations.servlet.ValidateLoginUser</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>servletMain</servlet-name>
<url-pattern>/validateLoginUser</url-pattern>
</servlet-mapping>
and change that forward to:
this.getServletContext().getRequestDispatcher("/validateLoginUser").forward(request, response);
And do the same with your other class from the same package.
You seem to be relying on the legacy InvokerServlet which is known to have major security holes. This was deprecated in Tomcat 5 and clones (WebSphere 4) and removed in Tomcat 7 and clones (WebSphere 6).
You're not supposed to use it anymore. Just map the servlet on a normal URL pattern and invoke it. Assuming that the servlet is mapped on an URL pattern of /validateLoginUser via #WebServlet("/validateLoginUser") annotation on the servlet class, or via <url-pattern>/validateLoginUser</url-pattern> in web.xml mapping on the servlet, then you can get a request dispatcher on it as below:
request.getRequestDispatcher("/validateLoginUser");
Or, just refactor shared code to a plain Java class with a method and invoke it the usual Java way. It's these days kind of weird to have shared validation logic tight coupled in a servlet.
See also:
How to invoke a servlet without mapping in web.xml?
To make above upgrade working, I did few other changes as below for future references.
Mainly, I have to change binding files for websphere.
Previously, I had two bindings ibm-web-bnd.xmi and ibm-web-ext.xmi
ibm-web-bnd.xmi
<?xml version="1.0" encoding="UTF-8"?>
<com.ibm.ejs.models.base.bindings.webappbnd:WebAppBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.ejs.models.base.bindings.webappbnd="webappbnd.xmi" xmi:id="WebAppBinding_1226331113121" virtualHostName="default_host">
<webapp href="WEB-INF/web.xml#WebApp"/>
<resRefBindings xmi:id="ResourceRefBinding_1226331113121" jndiName="AffinaDataSource_pma">
<bindingResourceRef href="WEB-INF/web.xml#ResourceRef_AffinaDataSource_pma"/>
</resRefBindings>
</com.ibm.ejs.models.base.bindings.webappbnd:WebAppBinding>
ibm-web-ext.xmi
<?xml version="1.0" encoding="UTF-8"?>
<com.ibm.ejs.models.base.extensions.webappext:WebAppExtension
xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:com.ibm.ejs.models.base.extensions.webappext="webappext.xmi"
xmi:id="WebAppExtension_1226331113121"
serveServletsByClassnameEnabled="true">
<webApp href="WEB-INF/web.xml#WebApp"/>
<jspAttributes xmi:id="JSPAttribute_1226331113121" name="reloadEnabled" value="true"/>
<jspAttributes xmi:id="JSPAttribute_1226331113122" name="reloadInterval" value="10"/>
</com.ibm.ejs.models.base.extensions.webappext:WebAppExtension>
So as per servlet3 and Websphere 8.5.5.8, I change to replace above two .xmi files with ibm-web-bnd.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
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="AffinaDataSourceAlias_pma" binding-name="AffinaDataSource_pma"/>
</web-bnd>
and then while installing application on Websphere 8.5.5.8, it use to throw outofmemmory error, so to fix that I change below max memory parameter from 256m to 512m in wsadmin.bat
C:\WebSphere858\AppServer\bin\wsadmin.bat
set PERFJAVAOPTION=-Xms256m -Xmx512m -Xquickstart
Hope this helps.
I need to consume a web service in my project. I use NetBeans so I right-clicked on my project and tried to add a new "Web Service Client". Last time I checked, this was the way to create a web service client. But it resulted in an AssertionError, saying:
java.lang.AssertionError: org.xml.sax.SAXParseException; systemId: jar:file:/path/to/glassfish/modules/jaxb-osgi.jar!/com/sun/tools/xjc/reader/xmlschema/bindinfo/binding.xsd; lineNumber: 52; columnNumber: 88; schema_reference: Failed to read schema document 'xjc.xsd', because 'file' access is not allowed due to restriction set by the accessExternalSchema property.
The default Java platform for NetBeans was JDK8 (Oracle's official version), so when I changed my netbeans.conf file and made JDK7 (from Oracle, as well) as my default, everything worked fine. So I think the problem is with JDK8. Here is my java -version output:
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
For now, I'm keeping JDK7 as my default Java platform. If there is a way to make JDK8 work please share.
Well, I found the solution. (based on http://docs.oracle.com/javase/7/docs/api/javax/xml/XMLConstants.html#ACCESS_EXTERNAL_SCHEMA)
Create a file named jaxp.properties (if it doesn't exist) under /path/to/jdk1.8.0/jre/lib and then write this line in it:
javax.xml.accessExternalSchema = all
That's all. Enjoy JDK 8.
Not an actual answer but more as a reference.
If you are using the jaxws Maven plugin and you get the same error message, add the mentioned property to the plugin configuration:
...
<plugin>
<groupId>org.jvnet.jax-ws-commons</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.3</version>
<configuration>
<!-- Needed with JAXP 1.5 -->
<vmArgs>
<vmArg>-Djavax.xml.accessExternalSchema=all</vmArg>
</vmArgs>
</configuration>
</plugin>
I run ant builds within Eclipse IDE (4.4, Luna, on Windows 7 x64). Rather than modifying the installed JRE lib or any ant scripts (I have multiple projects that include XJC in their builds), I prefer to change Eclipse Settings "External Tools Configurations" and add the following to the VM arguments for the Ant build configuration:
-Djavax.xml.accessExternalSchema=all
The following works for wsimport 2.2.9 included in jdk 1.8.0_66:
wsimport -J-Djavax.xml.accessExternalSchema=all ....
In my case adding:
javax.xml.accessExternalSchema = all
to jaxp.properties didn't work, I've to add:
javax.xml.accessExternalDTD = all
My environment is linux mint 17 and java 8 oracle.
I'll put it there as an answer for people with the same problem.
I tested this for version 2.4 of artifact org.codehaus.mojo and that worked ~
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.4.1</version>
<executions>
<execution>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<wsdlDirectory>path/to/dir/wsdl</wsdlDirectory>
</configuration>
<id>wsimport-web-service</id>
<phase>generate-sources</phase>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>javax.xml</groupId>
<artifactId>webservices-api</artifactId>
<version>${webservices-api-version}</version>
</dependency>
</dependencies>
<configuration>
<vmArgs>
<vmArg>-Djavax.xml.accessExternalSchema=all</vmArg>
</vmArgs>
<sourceDestDir>generated-sources/jaxws-wsimport</sourceDestDir>
<xnocompile>true</xnocompile>
<verbose>true</verbose>
<extension>true</extension>
<sei>/</sei>
</configuration>
</plugin>
</plugins>
Here is a hint Hint for gradle users without admin rights: add this line to your jaxb-task:
System.setProperty('javax.xml.accessExternalSchema', 'all')
it will look like this:
jaxb {
System.setProperty('javax.xml.accessExternalSchema', 'all')
xsdDir = "${project.name}/xsd"
xjc {
taskClassname = "com.sun.tools.xjc.XJCTask"
args = ["-npa", "-no-header"]
}
}
If you are getting this problem when converting wsdl to jave with the cxf-codegen-plugin, then you can solve it by configuring the plugin to fork and provide the additional "-Djavax.xml.accessExternalSchema=all" JVM option.
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>${cxf.version}</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<fork>always</fork>
<additionalJvmArgs>
-Djavax.xml.accessExternalSchema=all
</additionalJvmArgs>
I was also getting similar type of error in Eclipse during testing a webservice program on glassfish 4.0 web server:
java.lang.AssertionError: org.xml.sax.SAXParseException; systemId: bundle://158.0:1/com/sun/tools/xjc/reader/xmlschema/bindinfo/binding.xsd; lineNumber: 52; columnNumber: 88; schema_reference: Failed to read schema document 'xjc.xsd', because 'bundle' access is not allowed due to restriction set by the accessExternalSchema property.
I have added javax.xml.accessExternalSchema = All in jaxp.properties, but doesnot work for me.
However I found a solution here below which work for me:
For GlassFish Server, I need to modify the domain.xml of the GlassFish,
path :<path>/glassfish/domains/domain1 or domain2/config/domain.xml) and add, <jvm-options>-Djavax.xml.accessExternalSchema=all</jvm-options>under the <java-config> tag
....
<java-config>
...
<jvm-options>-Djavax.xml.accessExternalSchema=all</jvm-options>
</java-config>
...and then restart the GlassFish server
Enabling Access to External Schema
You need to enable the IDE and the GlassFish Server to access external schema to parse the WSDL file of the web service. To enable access you need to modify the configuration files of the IDE and the GlassFish Server. For more details, see the FAQ How to enable parsing of WSDL with an external schema?
Configuring the IDE
To generate a web service client in the IDE from a web service or WSDL file you need to modify the IDE configuration file (netbeans.conf) to add the following switch to netbeans_default_options.
-J-Djavax.xml.accessExternalSchema=all
For more about locating and modifying the netbeans.conf configuration file, see Netbeans Conf FAQ.
Configuring the GlassFish Server
If you are deploying to the GlassFish Server you need to modify the configuration file of the GlassFish Server (domain.xml) to enable the server to access external schemas to parse the wsdl file and generate the test client. To enable access to external schemas, open the GlassFish configuration file (GLASSFISH_INSTALL/glassfish/domains/domain1/config/domain.xml) and add the following JVM option element (in bold). You will need to restart the server for the change to take effect.
</java-config>
...
<jvm-options>-Djavax.xml.accessExternalSchema=all</jvm-options>
</java-config>
Create a file named jaxp.properties (if it doesn’t exist) under path to your "JDK version/jre/lib" and then add the following line in it.
javax.xml.accessExternalSchema = all
When using Maven with IntelliJ IDE you can add -Djavax.xml.accessExternalSchema=all to Maven setting under JVM Options for Maven Build Tools Runner configuration
This works on jdk1.8.0_65
wsimport -J-Djavax.xml.accessExternalSchema=all -keep -verbose https://your webservice url?wsdl
For those using the ANT task wsimport, a way of passing the option as suggested by #CMFly and specified in the documentation is the following:
<wsimport
<!-- ... -->
fork="true"
>
<jvmarg value="-Djavax.xml.accessExternalSchema=all"/>
</wsimport>
It is now fixed in 2.5 version (released in jul/17). https://github.com/mojohaus/jaxws-maven-plugin/issues/8.
For the 2.4.x versions there is a workaround (as decribed in https://github.com/mojohaus/jaxws-maven-plugin/issues/4):
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.4.1</version>
<dependencies>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-tools</artifactId>
<version>2.2.10</version>
</dependency>
</dependencies>
</plugin>
I used it with a regular maven project, and got it solved with this plugin dependency configuration for running the xjc plugin:
<plugin>
<!-- Needed to run the plugin xjc en Java 8 or superior -->
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<id>set-additional-system-properties</id>
<goals>
<goal>set-system-properties</goal>
</goals>
</execution>
</executions>
<configuration>
<properties>
<property>
<name>javax.xml.accessExternalSchema</name>
<value>all</value>
</property>
<property>
<name>javax.xml.accessExternalDTD</name>
<value>all</value>
</property>
</properties>
</configuration>
</plugin>
Another solution to address: wiki.netbeans.org
The Web Service Client wizard in the IDE parses the WSDL file when generating a web service client from a web service or WSDL file. You need to modify the IDE configuration file (netbeans.conf) to add the following switch to the netbeans_default_options. You will need to restart the IDE for the change to take effect.
-J-Djavax.xml.accessExternalSchema=all
When deploying to GlassFish you need to enable access to external schema to generate a test client for a web service. To enable access you need to modify the configuration file of the GlassFish Server (GLASSFISH_INSTALL/glassfish/domains/domain1/config/domain.xml) and add the following JVM option element. You will need to restart the server for the change to take effect.
</java-config>
...
<jvm-options>-Djavax.xml.accessExternalSchema=all</jvm-options>
</java-config>
I have just tried that if you use SoapUI (5.4.x) and use Apache CXF tool to generate java code, put javax.xml.accessExternalSchema = all in YOUR_JDK/jre/lib/jaxp.properties file also works.
If you are using ant you can add a jvmarg to your java calls:
<jvmarg value="-Djavax.xml.accessExternalSchema=all" />
Another alternative is to update wsimport.sh shell script by adding the following:
The wsimport.sh is located in this directory:
jaxws-ri.2.2.28/bin
exec "$JAVA" $WSIMPORT_OPTS -Djavax.xml.accessExternalSchema=all -jar "$JAXWS_HOME/lib/jaxws-tools.jar" "$#"
Another reference:
If you are using the maven-jaxb2-plugin, prior to version 0.9.0, you can use the workaround described on this issue, in which this behaviour affected the plugin.
NetBeans update their tutorial for JDK8 and this Issue:
Getting Started with JAX-WS Web Services -> Enabling Access to External Schema
A very simple portable solution would be, to place the following line of code somewhere in a crucial part of your code, a part of which you are sure that it will be run (for example right in the main method):
System.setProperty("javax.xml.accessExternalDTD", "all");
This sets the needed system property programmatically, without having to do tricky maven pom.xml changes (which for some reason didn't work for me).
If you are using Intellij IDEA, in the maven tool window
select Maven Settings and expand the Maven drop down and select Runner.
Under the VM Options add -Djavax.xml.accessExternalSchema=all
Using RAD 9.6 with JDK 1.8 websphere 8.5 runtime on Windows,
editing the xjc.bat as in Generate Java gives "Failed to read external schema..." error didn't work with me, adding/updating the jaxb.properties didn't work as well,
however I edited the wsimport as in below note
you may modify the wsimport.bat file to specify the property directly as one of the jvm arguments like below:-Djavax.xml.accessExternalSchema=all
Our customers reported that the above solution worked for them.
as mentioned in SAXParseException, and it was the solution in my case.
I creating a Java EE 7 project using Eclipse Maven plugin. My problem is when I run the application the class that implements SerlvetContextListener does not get invoked. What is causing this problem?
#WebListener
public class ApplicationContextListener implements ServletContextListener{
#Override
public void contextInitialized(ServletContextEvent sce)
{
Request request = new HttpRequest(sce);
new Thread (request).start();
HibernateUtil.getSessionFactory();
}
#Override
public void contextDestroyed(ServletContextEvent sce)
{
}
}
web.xml:
<?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">
<listener>com.kyrogaming.AppServletContextListener</listener>
<!-- Jersey Mapping -->
<servlet>
<servlet-name>jersey-servlet</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>com.kyrogaming.webservices</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>jersey-servlet</servlet-name>
<url-pattern>/service/*</url-pattern>
</servlet-mapping>
<!-- end Jersey Mapping -->
<welcome-file-list>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
</web-app>
To summarize JNL's and Ted Goddard's answers:
For a ServletContextListener (or other listeners, such as a ServletContextAttributeListener or a ServletRequestAttributeListener) to be loaded by the servlet container, you need to tell the container about it. As described in the API docs, there are three ways to do this:
Declare it in the deployment descriptor (web.xml):
com.kyrogaming.AppServletContextListener
or annotate its class with #WebListener (see "Note about annotations" below)
or register it programatically, via the methods in ServletContext, such as addListener().
Note about annotations
Method 1) and 3) will always work. For method 2) (annotations) to work, the servlet container must be configured to scan the classes in the classpath, to find the annotated listener classes.
The webapp's own classes (under WEB-INF/classes) and libraries (JARs under WEB-INF/lib) will not be scanned if the web.xml contains the attribute metadata-complete="true" (the attribute defaults to false). See the Java Servlet Specification Version 3.0, chapter 8.1, "Annotations and pluggability".
In a web application, classes using annotations will have their annotations processed only if they are located in the WEB-INF/classes directory, or if they are packaged in a jar file located in WEB-INF/lib within the application. The web application deployment descriptor contains a new “metadata-complete” attribute on the web-app element. The “metadata-complete” attribute defines whether the web descriptor is complete, or whether the class files of the jar file should be examined for annotations and web fragments at deployment time. If “metadata-complete” is set to "true", the deployment tool MUST ignore any servlet annotations present in the class files of the application and web fragments. If the metadata-complete attribute is not specified or is set to "false", the deployment tool must examine the class files of the application for annotations, and scan for web fragments.
So, to allow the container to find annotated classes in JARs, make sure the web.xml sets metadata-complete="false", or does not set it at all.
Note that setting this may delay the application startup; see for example What to do with annotations after setting metadata-complete="true" (which resolved slow Tomcat 7 start-up)? .
Unfortunately, that still does not explain why the ServletContextListener in the question is not loaded. Note that the web.xml in the question does not metadata-complete, meaning it defaults to false, thus classpath scanning is enabled. There is probably some other problem; this checklist hopefully helps in finding it.
Using metadata-complete="false" in web.xml fixed this issue for me.
<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"
metadata-complete="false">
In web.xml you also need to specify the <listener-class>.
<listener>
<listener-class>
com.kyrogaming.AppServletContextListener
</listener-class>
</listener>
For the record, I'm adding yet another possible (and rather vicious) cause of ServletContextListener not being invoked.
This can happen when you have a java.lang.LinkageError, that is when you forgot to add <scope>provided</scope> to your javax.servlet-api dependency.
In such a case the listener instance is created but only the static part is executed, not the contextInitialized and contextDestroyed methods.
You shall discover only when you invoke some servlet, as the linkage error is not raised during listener instantiation.
There is one other extremely rare scenario which can cause this. (which took me 4 hours to uncover)
If you're using Tomcat10 then you can't use javax.servlet library in your maven/gradle.
Tomcat9 still has javax.servlet, but Tomcat10 migrated to jakarta.servlet
Tomcat10 expects to have Listener class that uses jakarta.servlet.ServletContextListener
So use this maven dependency: (scope is provided, because Tomcat10 already has such library)
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>5.0.0</version>
<scope>provided</scope>
</dependency>
The running container might need to explicitly allow scanning for annotations:
Ex for jetty:
cd [JETTY_BASE]
java -jar [JETTY_HOME]/start.jar --add-module=annotations
In a Spring-Boot 1.3+ scenario, you need to have the package for the class annotated with #WebListener (and #WebFilter, #WebServlet) fall under the #ServletComponentScan package scope.
Per Baeldung.
I'm trying to load images (and other static content) from a server outside of my web application which is deployed to Glassfish v3. I have the following configs in the web.xml but it does not work on Glassfish (but it works on Tomcat):
<servlet>
<servlet-name>ExternalImagesServlet</servlet-name>
<servlet-class>com.example.servlet.HttpProxyServlet</servlet-class>
<init-param>
<param-name>RemoteURI</param-name>
<param-value>http://ip.of.second.server/website-files</param-value>
</init-param>
<init-param>
<param-name>AllowedContentTypes</param-name>
<param-value>image/gif,image/jpeg,image/png</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>ExternalImagesServlet</servlet-name>
<url-pattern>/images/*</url-pattern>
</servlet-mapping>
Where ip.of.second.server is an actual IP address of the server. I have the file called website-files.xml defined as follow:
<?xml version="1.0" encoding="UTF-8"?>
<Context docBase="d:/internet/website/images" />
And website-files.xml is saved to glassfish\domains\domain1\config directory. But Glassfish does not pick up this config file.
I have looked at Oracle Glassfish configuration doco but there's no mention on how you can reference images from a different server.
Please help.
I have solved it based on an old thread relating to Glassfish version 2 that I found on Google after two days of search.
In case anyone is interested in the solution, here it is:
1) Create a file called sun-web.xml directly under Webcontent\WEB-INF directory and add the following configuration to this file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD GlassFish Application Server 3.0 Servlet 3.0//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_3_0-0.dtd">
<sun-web-app>
<property name="alternatedocroot_1" value="from=/images/* dir=d:/internet/website" />
<property name="alternatedocroot_2" value="from=/files/* dir=d:/internet/website" />
</sun-web-app>
2) Remove the servlet and servlet-mapping configurations from web.xml file (like I did above). Note: The above would work if you were to use Tomcat.
3) Delete the website-files.xml from glassfish\domains\domain1\config directory as this file is not needed by Glassfish: Note: This file is needed by Tomcat.