I have an EAR project, which contains my application's version number in its name. Inside it I have a JAR for my session beans (the JAR also has a version number in its name). Inside that jar, I have a web service implementation.
So far so good. The problem is that the path to the WSDL is something like: host:port/application_name_and_version-jar_name_and_version/WS_name?WSDL. This means that every time a new version comes along, the WS client has to be adjusted.
This whole thing is deployed in JBoss.
The question is, how do I change the URL so it does not contain version numbers? I assume it has to do with deployment descriptors, but so far I was unable to find any useful information on this.
I would make a .war file containing only the web service implementation, then give the war its own context root inside the .ear file's application.xml. For example:
<application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="5" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd">
<module>
<java>shared-code.jar</java>
<module>
<ejb>my-ejbs.jar</ejb>
</module>
<module>
<web>
<web-uri>my-web-service.war</web-uri>
<context-root>webserviceroot</context-root>
</web>
</module>
<library-directory>lib</library-directory>
</application>
Sorry about the formatting, I can't get StackOverflow to make a contiguous code block from the above after messing with it a bit.
Anyway, if you deploy an .ear file like that, then you should be able to access http://host:port/webserviceroot/... instead.
Related
Excuse me, I'm new to this. I have developed an application with maven, and when I run the application in my wildfly it opens the following path: "127.0.0.1:8080/myapp-1.0.0" and everything runs perfect, but I simply want that:
x.x.x.x/ point to: x.x.x.x:8080/myapp-x.x.x
I do not know if it is a configuration in standalone.xml as it redirects or something more complicated.
If you only have a single web application, the simplest way is to have jboss-web.xml file in your web application. Put a file like:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web version="10.0"
xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd">
<context-root>/</context-root>
</jboss-web>
in your WEB-INF directory. This will make your application run at the / context. Note that this isn't redirection - it's permanently there. Additionally, if you have many webapps running on your Wildfly server they will all need a unique context root.
I have a Java class that has a #WebService annotation and is packaged in a WAR. When deploying the WAR to different JavaEE 6 application servers I want to have the same URL (of course with different hosts and ports...).
The default naming seems to be appserver-dependent. Some examples:
Glassfish:
http://{hostname or ip}:{port}/{service name}/{port name}
JBoss:
http://{hostname or ip}:{port}/{ejb-jar-name}/{service name}/{port name}
WebSphere:
http://{hostname or ip}:{port}/{ejb-jar-name}/{service name}
What is the easiest way for configuring this for all server vendors?
If you are creating a web service based in a POJO class, then you only need to pack your war file inside an ear file and define the context root of the web module in the application.xml configuration file.
Here is an application.xml file example:
<?xml version="1.0" encoding="UTF-8"?>
<application 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/application_5.xsd" version="5">
<display-name>simple-ws-app</display-name>
<module>
<web>
<web-uri>simple-ws-war.war</web-uri>
<context-root>/simple-ws-app</context-root>
</web>
</module>
<library-directory>lib</library-directory>
</application>
In the annotation #WebService you can configure the expected web service configuration, if you have a wsdl file then is easier to define the web service. Here is an example of the complete #WebService annotation configuration, use only the properties you need.
#WebService(name = "SimpleService",
serviceName = "SimpleService",
portName = "SimpleServicePort",
endpointInterface = "simple.ws.srv.SimpleServicePortType",
targetNamespace = "http://www.ws.simple/srv",
wsdlLocation = "WEB-INF/wsdl/simple-ws.wsdl"
)
Note that if you are using a wsdl file the default location to place it is inside WEB-INF/wsdl.
Now, the expected wsdl URL for this configuration is
http://hostname:port/simple-ws-app/SimpleService?wsdl
This may not work fot all app-servers, I know it works for Glassfish, WildFly and Weblogic.
Finally, the default naming for enterprise web services (for example EJB WebServices, ejb-jar inside ear file) is in deed appserver-dependent. I've been googling and trying to accomplish this configuration for several months with the same result. No matters if you provide a complete #WebService annotation configuration including a valid wsdl with the expected endpoint configuration, app-servers override the wsdl endpoint URL.
I have a java application which needs to be deployed in the weblogic server. I am currently making the ear file for that application. My ear file has an ejb jar inside. I want to add log4j2 jars to this application. So my folder structure is
> Project-Name-
> --Ear-Content
> --APP-INF
> --lib -> log4j2 jars
> --classes - > log4j2.xml
> --META-INF->application.xml, MANIFEST.MF, weblogic-application.xml
> --Project-Name.jar
Currently I have put the jars in APP-INF folder/lib and in META-INF/application.xml I have put the jars in modules. Here is my application.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN' 'http://java.sun.com/dtd/application_1_3.dtd'>
<application>
<display-name>ProjectName</display-name>
<description>ProjectName</description>
<module>
<ejb>ProjectName.jar</ejb>
</module>
<module>
<java>lib/log4j-api-2.1.jar</java>
</module>
<module>
<java>lib/log4j-core-2.1.jar</java>
</module>
</application>
But it is not taking the log4j jars. Any solutions ??
If you are only packaging up one application, I would highly recommend using a war file instead of an ear since it is simpler. Otherwise you may need to package your current Project-Name.jar into a war file and then package that into the ear.
See a tutorial like the one here
That said - you should not need to explicitly reference the log4j libraries in your application.xml file with module tags. From the Oracle docs:
The classes and libraries stored under APP-INF/classes and APP-INF/lib
are available to all modules in the Enterprise Application. The
application classloader always attempts to resolve class requests by
first looking in APP-INF/classes, then APP-INF/lib.
Last but not least, if it seems like Weblogic is not using the classes you want it to and is instead using the defaults, in your case log4j 1.2 vs log4j 2, you will need to set the following in your application.xml to tell Weblogic which one to use:
<prefer-application-packages>
<package-name>org.apache.log4j.*</package-name>
</prefer-application-packages>
My scenario is the following:
I have a WebApp.war that is deployed to a servlet container. This WebApp.war contains in WEB-INF/lib the following libraries:
lib_a.jar
lib_b.jar
I have one other library, say lib_vendor.jar, that I cannot deploy within WebApp/WEB-INF/lib because of licensing issues so I let our customers to copy this library in tomcat/lib after application installation. But since lib_vendor.jar requires lib_a.jar and lib_b.jar that are loaded in the web application class loader, I cannot use lib_vendor.jar.
How can I load an external library (not in WEB-INF/lib) in the same classloader of a web application?
Since you are using Tomcat, you could leverage the VirtualWebappLoader.
Add a META-INF/context.xml whith
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/somepath/myapp">
<Loader className="org.apache.catalina.loader.VirtualWebappLoader"
virtualClasspath="/somedir/*.jar"/>
</Context>
Remember also that the virtualClasspath attribute must be a absolute path, as correctly stated in the comment below.
I have built an ear with this structure (not all files shown here):
myapp.ear/
myapp-ejb.jar
myapp-web.war
META-INF/
application.xml
lib
myapp-common.jar
The problem is, when code in the war tries to reference classes in myapp-common.jar, it throws java.lang.ClassNotFoundException.
Note the contents of META-INF/application.xml:
<?xml version="1.0" encoding="UTF-8"?>
<application 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/application_6.xsd"
version="6">
<display-name>pncr-portal-ear</display-name>
<module>
<web>
<web-uri>myapp-web.war</web-uri>
<context-root>/</context-root>
</web>
</module>
<module>
<ejb>myapp-ejb.jar</ejb>
</module>
<library-directory>/lib</library-directory>
</application>
The library directory is defined here as being in the /lib directory relative to the root of the ear, which is exactly where it is, yet it is not loaded into the classpath despite the Java EE 5 (and presumably 6) spec saying that it should be loaded into the classpath.
As it turns out, I was referencing a class in a slightly different package than the one I thought. The package no longer existed, yet Maven was compiling it without complaining. So I blew away my local repository and tried again. I still got the error. Then I found the problem: In myapp.taglib.xml, I am still referencing an old version of a class in myapp-common.jar that is now in a different package.
So the lesson is: If you see ClassNotFoundException, also look in your taglib.xml file(s).
Verify that you have META-INF/manifest.mf in your war file, containing (something like):
Manifest-Version: 1.0
Class-Path: lib/myapp-common.jar