I am in the process of moving to Jetty from another container. I need to set some custom JSP configuration for JettyJspServlet etc. I'm doing that via web.xml:
<servlet id="jsp">
<servlet-name>jsp</servlet-name>
<servlet-class>org.eclipse.jetty.jsp.JettyJspServlet</servlet-class>
(...)
However, these web.xml settings fail for the previous container, and I would like to maintain compatibility for a while.
Is there a way to apply these settings only when the WAR is deployed to Jetty, and not alter Jetty configuration. Thing is I want to set them at WAR packaging level as not to force people to use custom Jetty configuration via jetty.base etc.
I tried setting overrideDescriptor to override-web.xml via WEB-INF/jetty-web.xml and while jetty-web.xml file is read, the override descriptor seems to be ignored completely.
If you are on a Servlet Container and have JSP enabled, you shouldn't be required to use the <servlet-class> element, as that would be container specific.
But all Servlet containers that have JSP must expose the named servlet jsp, so just rely on the name and configure it without a class.
Change it to just ...
<servlet id="jsp">
<servlet-name>jsp</servlet-name>
<!-- no servlet class here -->
<init-param>
(...)
That should be safe to use on all containers.
Related
I am migrating to Wildfly 8.2 from JBoss 5.1, I am deploying a Web Service using the resteasy and some EAR which has the code to get the requested data from the DB. Both the EAR which has multiple (6) JARs, but when I call the Web Service, it is not able to find the EAR and refer it's JARs
14:57:48,183 INFO [stdout] (default task-4) InitialContextFactory not defined - using default: org.jnp.interfaces.NamingContextFactory
14:57:48,184 ERROR [stderr] (default task-4) javax.naming.NameNotFoundException: bpc/AccountManagementService -- service jboss.naming.context.java.bpc.AccountManagementService
I have 2 separate deployment of EAR and WAR and both of them are deployed simultaneously and they both get deployed without any hassle.
Why are then not able to integrate is my issue right now.
If you migrated from jboss 5 to wildfly, you have to adjust your jndi lookups.. You are getting a NameNotFoundException, so probably you are performing a lookup using the old jndi syntax..
When you startup your server, the log will show you different jndi names for your ejbs..
If you are looking for an ejb from a war, and both of them are not bundled in the same ear, then you have to use the java:global naming type..
For example, assuming that AccountManagementService is an interface, annotate it with #Remote, and search it from your war using the following jndi syntax
java:global/earName/ejb-jar-name/AccountManagementService!com.example.AccountManagementServiceImpl
See if this document helps (Modify JNDI lookup code section) https://docs.jboss.org/author/display/AS71/Order+Application+Migration+from+EAP5.1+to+AS7
I resolved this issue by adding jboss-deployment-structure.xml in my WAR file under the web-inf folder
by adding dependency like
dependencies>
<module name="deployment.MY_EAR.ear.MY_EJB_JAR.jar"/>
</dependencies>
I have similar issue.
I am migrating from weblogic to wildfly.
One JAR which has only one property file and one EAR, both are deployed simultaneously without any issue.
From EAR application, need to access the property file from the JAR.
This is working fine in weblogic but wildfly not identifying the property file.
How I can get my web service client (in a web application) uses the web.xml file to get the source of the wsdl?
I am using netbeans 6.9 and tomcat, and so far we have in our web application a web services references with the url of the wsdl.
I do not recommend to store such resources in web.xml, because they can be changed in future. For e.g. if the web service which is deployed in http://theaddress:8080/webapp?wsdl will be migrated to some other server and URL will change. Then you have to modify your application in which case it is not very efficient way.
I would suggest JNDI to store resource like this. Read how to do this in Tomcat, it is not hard to set up.
The alternative is to use .properties files, but I'd rather choose JNDI over .properties.
If it must be the web.xml, you can configure a context parameter(like any other) like:
<context-param>
<param-name>webservice.Location</param-name>
<param-value>http://theaddress:8080/webapp?wsdl</param-value>
</context-param>
After configuring as above (the Webservice.Location) is an arbitrary variable name you can change to suit your needs. If you're not using any add-on web application layers like JSF or Struts etc, you can now reference this variable(from the HttpServletRequest object) like so in a servlet
String webServiceAddr = request.getServletContext().getInitParameter("webservice.Location"); //getServletContext() will give you an instance to a ServletContext object which basically is a representation of your entire web application deployment environment including configuration files.
The variable webServiceAddr will now contain the configured value
I advise though you externalise such a config to a standard .properties file as it's a little bit risky having a deployer mucking about with other configurations in your web.xml while trying to set it up. It's also best practice in configuration management for applications. A small tutorial on properties files here
I am using GWTTestCase class and I have to specify any servlets to use in module.gwt.xml file using
<servlet path="/somepath" class="com.example.SomeServlet"/>.
The actual requirement is to load other servlets that initialize resources (using GenericServlet.init() method) in order to make the tests run. web.xml is the obvious choice as this works in normal application setup. Also it would be useful to declare initialisation parameters.
How do I get GWT to read web.xml file when doing unit testing?
I think you'll have to:
extend your servlet and override the init() method to pass the appropriate parameters
configure that servlet in your *.gwt.xml (I'd suggest using a module specifically for the test(s), so that the <servlet> don't clutter your production module)
As an alternative, because this looks more like an integration test than a unit test, don't use a GWTTestCase but rather WebDriver/Selenium and a lightweight servlet container configured specifically for your test (e.g. Jetty).
I would try Google Guice with its servlet extension. It allow you to dynamically bind servlets instead of web.xml. Real nice. You can load a specific testing module for example. The official docu has examples for the servlet extension. Hopefully it will provide you with what you need.
I'd like to have my Axis2 Web Service read from a configuration file, whose name is sent as a parameter to the service.
Where is the best place to put this file? And How to best access it? Examples welcome.
I've checked the current directory is the Apache/Tomcat/bin file, I could put it in the parent directory, or put it into a Apache/Tomcat/conf, although this looks like it's more reserved for apache configuration itself.
You don't want to load a configuration file on each request, which means configuration needs to be loaded ideally on startup.
In my experience that leaves you with two choices:
Embedded Spring container
JNDI
The former approach is described in the Axis2 documentation, the latter approach depends on the appserver/container you're using.
An example if JNDI configuration for jetty is here:
I have a webapp (http://sourceforge.net/projects/sf-mvn-plugins/files/m2-repo/net/sf/maven/plugins/example-captaincasa-jnlp/0.1-SNAPSHOT/example-captaincasa-jnlp-0.1-SNAPSHOT.war/download) which uses jsf in a servlet container. This works fine with jetty-maven-plugin run-war target at my local pc. In the future I would like make more of this kind of webapps.
I am looking for a way to deliver these webapps with jetty via jnlp. The end user should be have a zero installation but the webapps needs servlet container and my hoster does not support a servlet container or application server or so on.
I don't like an embedded solution because in this case each webapp must be delivered with a separate jetty und run with a separate jetty -> too big size -> to many download size and so on.
The architecture should be similar to this:
(source: sourceforge.net)
Example: Bundle1 could contains jetty and deployed webapp1 and Bundle2 could contains jetty and deployed webapp1 and webapp2 (related to requirements of end user I would like deliver many variant of my webapps)
But what is my question?
Which jars of jetty are needed? I would like these upload to my homepage for hosting.
Which jar should I use for jetty as main jar to start him via jnlp?
Which main class should I use to start jetty via jnlp?
Which parameter could I use to configure jetty to say this is war of webapp1 and this is war of webapp2.... or this is directory of weapps for hot deployment...?
The important question for me is 1. If this is answered so that I could run jetty local (without maven plugin) and via manual maybe I could solve the rest 2-4.
Why not deploy a normal Java app (with a main() etc.) that invokes Jetty programatically via its Server class? That class is configured via code with the appropriate contexts, servlet classes etc.
I've done that before with success. The only headache is running one Jetty with multiple apps being downloaded on request (if I read your question correctly). Can you use some classloading magic, and load classes/apps on demand from a remote URL ?
I have found another way today. This is interesting too. Here is the concept:
Use java webstart to install an osgi container
Use a bundle x or a osgi service to download all bundles of your app
Use the jetty bundle to provide jetty support
Then the application is installed
I got the idea from this article:
http://www.toedter.com/blog/?p=45