I understand Websphere 8.0.0.6 uses the Apache Wink implementation for JAX-RS 1.1.
I'm just wondering what version of Apache Wink does it use?
Also, if I needed to use Apache CXF do I just bundle the CXF jars with my war?
ALso what implementations does Websphere 8.0.0.6 use for CDI (Weld 2.x ??), Bean Validation (??), JPA (??), JAXB (??) etc..
WAS v8.0.0.x uses it's own modified version of Wink v1.1-incubating. If you navigate to {WAS_HOME}/plugins, you'll see a .jar named com.ibm.ws.jaxrs.jar. If you explore the MANIFEST within that artifact, you'll see that IBM modified Wink v1.1-incubating and created their own v1.1.1. You'll want to use this version, because it incorporates wink-jcdi-server. Otherwise, you can't inject your EJB's into your Wink Resources, which creates a number of annoying problems. I generally don't like to shackle myself to a vendor-specific solution, but in this case, you're going to want to use IBM's Wink implementation. I've backported wink-jcdi-server from v1.2-incubating to v1.1-incubating with temporary success (I got the jcdi feature to work, but then, with no determined root cause, lost it a few deployments later). So, save yourself tons of frustration and use IMB's Wink implementation. IBM's Wink implementation will be exposed to your app, via an OSGi-related artifact, whether you set the classloader policy to PARENT_FIRST or PARENT_LAST. I suspect that is a bug. You'll also need to include the com.ibm.ws.prereq.jaxrs.jar artifact in your project as well.
In web.xml, use the following config:
<!-- Wink Servlet -->
<servlet>
<description>JAX-RS Tools Generated - Do not modify</description>
<servlet-name>JAX-RS Servlet</servlet-name>
<servlet-class>com.ibm.websphere.jaxrs.server.IBMRestServlet</servlet-class>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.company.webservices.config.WinkApplication</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
<enabled>true</enabled>
<async-supported>false</async-supported>
</servlet>
<!-- Wink Servlet Mapping -->
<servlet-mapping>
<servlet-name>JAX-RS Servlet</servlet-name>
<url-pattern>/resources/*</url-pattern>
</servlet-mapping>
According to IBM's own WAS v8.0 video on JAX-RS, your Application subclass will get automatically recognized by extending the Application class and the ApplicationPath annotation. This is not the case. You need to specify your Application subclass in web.xml. However, you'll notice that the console will tell you that the default Wink Application was used. This is false. Your class will get picked up, and you'll need to override the getClasses method and register your Providers, Resources, etc. This behavior has been observed and thoroughly tested as of WAS v8.0.0.8.
You could try CXF in WAS 8 as an alternative.
Like Geronimo and TomEE, WAS is built on Apache products. I could be wrong, but, last I remember, WAS v8.0 uses Apache OpenWebBeans v1.0, Apache BVal v1.0, Apache OpenJPA v2.1.2-SNAPSHOT. I'm not sure about JAXB, but I think they use their own json4j framework. I use MOXy with surprisingly much success.
You can get detailed report about component versions by running versionInfo script located in WAS_HOME/bin directory. For example, for Linux:
./versionInfo.sh -file versionReport.txt -maintenancePackages -componentDetail
Specification versions are listed at Specifications and API documentation
Related
I have made a web application to be deployed in the Websphere server but i came up with a problem.
I have 20 servlets that use a common parameter so i have this declared on web.xml:
<context-param>
<param-name>filePath</param-name>
<param-value>C:\logs.txt</param-value>
</context-param>
I want this parameter to be easily edited in the Websphere console but doesn't work. I know this works on Tomcat but is there anything equivalent on websphere?
Thanks
You should edit web.xml only on the server, there is know interface for it in the Console, as I remember.
You can find this file here:{WAS_ROOT}/profiles/profilename/config/cells/cellname/applications/enterpriseappname/deployments/deployedname/webmodulename
Link to the documentation:
http://www-01.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/tweb_jsfengine.html
I'm looking for a way to set spring profile in jetty programmatically so that the application that the war file on the server used the given profile, this is my code:
final WebAppContext context = new WebAppContext();
context.setLogUrlOnStart(true);
context.setWar("target/deployables/myapp-rest/myapp-rest.war");
context.setContextPath("/" + TEST_APP_CONTEXT);
context.setParentLoaderPriority(true);
server.setHandler(context);
server.start();
I tried a couple of things but none of them seem to work... I need to pass -Dspring.profiles.active=myProfile
This is tested with Jetty 9.3 but webdefault.xml seem to also be available for lower versions (it's placement might be different though).
Go to $JETTY_HOME/etc and open webdefault.xml. Search for context-param in the file. Add this code somewhere below:
<context-param>
<param-name>spring.profiles.default</param-name>
<param-value>prod</param-value>
</context-param>
This will work if your web.xml (in the your-app.war file) doesn't contain this context-param.
Otherwise you could also use override-web.xml (docs) but you would need to configure it in jetty-web.xml and jetty-web.xml must be bundled inside the war... So YMMV, but I didn't want to change my war and webdefault.xml is an easier solution for me.
In Spring I have slf4j with log4j to resolve logging.
I put relative path in log4j.xml configuration, but when i execute app in Netbeans Tomcat and independent Apache Tomcat, relative path is different, and I must change manually.
My idea is obtain context realpath from Spring Controller and set it in log4j configuration in execution time. But I dont know...
How can I change file path param of log4j from Spring Controller?
Two suggestions for you to try:
Add a WebAppRootListener to your web.xml - this will configure a system property pointing (default to webapp.root, but you can customize using a context-param - see the Javadocs link) to the root of your web application, which you can then use in the log4j.properties/xml file:
<listener>
<listener-class>org.springframework.web.util.WebAppRootListener<listener-class>
<listener>
<!-- log4.appender.File=${webapp.root}/logs/web-app.log -->
Or use the Log4jConfigListener in your web.xml (which ultimately delegates to a Log4jConfigurer) - this is similar to the above, but allows you to define a custom log4j configu file and also allows for your web application to monitor the log4j config file for changes made at runtime and automatically update your loggers:
<context-param>
<!-- Configure Log4J from the following config file location -->
<param-name>log4jConfigLocation</param-name>
<param-value>/WEB-INF/log4j.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener<listener-class>
<listener>
I would also recommend you read the Javadocs for the above in detail - there are some gotchas with regards to deploying multiple webapps in Tomcat and sharing of system properties, but this can all be worked around (providing a custom key for each webapp, rather than the default ${webapp.root}
I am newbie in BIRT reporting. I am trying to integrate BIRT runtime as per solution given in this post here but it did not work. I also tried to find BirtEngineServlet from org.eclipse.birt.runtime_3.7.1.v20110913-1734.jar file but I could not find this class.
Can anybody please help me out?
2 hours later:
Ok so BirtEngineServlet is in viewservlets.jar file, it resides in:
birt-runtime-3_7_1\WebViewerExample\WEB-INF\lib.
Because BirtEngineServlet is found in viewServlets.jar and this jar is located under path I mentioned, I tried to copy all jars from above path into my application WEB-INF/lib folder and tried to access the test report by using URL suggested in linked post .The URL I used is: localhost:8080/myOwnWebapp/…. Now I am getting following exception:
File "/webcontent/birt/pages/layout/RequesterFragment.jsp" not found at
org.apache.jasper.servlet.JspServlet.handleMissingResource(JspServlet.java:412) at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
my web.xml has following code.
<servlet>
<servlet-name>EngineServlet</servlet-name>
<servlet-class>org.eclipse.birt.report.servlet.BirtEngineServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>EngineServlet</servlet-name>
<url-pattern>/output</url-pattern>
</servlet-mapping>
As per today you can easily integrate BIRT like any other API as maven dependency into existing Java EE applications.
<dependency>
<groupId>org.eclipse.birt.runtime</groupId>
<artifactId>org.eclipse.birt.runtime</artifactId>
<version>4.4.1</version>
</dependency>
Follow the Integrating Birt tutorial for coding details.
How can I integrate URL rewriting in my Glassfish v3 server?
The reason why I want to know this is that I am deploying a PHP application into my Glassfish server using Quercus.
But Quercus relies on mod_rewrite in the Apache Server to provide URL rewriting and this is not available in Glassfish.
Well, you have two options:
either front your GlassFish instance with Apache and use mod_rewrite
or use Tuckey's Url Rewrite Filter
I guess the former is not an option (or you wouldn't post this question). Regarding the later, you could adapt the solution given in Drupal on Glassfish with clean urls using Url Rewrite Filter. Basically, you'll have to:
Get Quercus's war and unpack it
Download the filter and unpack it inside Quercus (this will put the filter jar inside WEB-INF/lib and the urlrewrite.xml under WEB-INF)
Declare the filter in the web.xml (see the instruction)
"Port" your rewrite rules to the urlrewrite.xml file
repackage and deploy the war (or deploy it as an exploded archive)
I've been looking for the answer to this for a couple weeks.
Follow these instructions for JBoss:
http://tapomay.blogspot.com/2011/11/clean-urls-with-drupal-urlrewritefilter.html
He links to an article where one had done this for Tomcat: http://www.brianshowalter.com/blog/running_drupal_on_quercus
In a nutshell, you want to rewrite the URL only IF the requested file or directory do not exist on the system. This is why just UrlRewriteFilter is not enough. You have to add a class-filter to UrlRewriteFilter to check for this.
The instructions I linked to uses an older version of UrlRewriteFilter (3.2.0), it probably works just as well with the newer version (I did it with 3.2.0).
You will use that in conjunction with a class filter (there is a google project repository for this, thanks to the author of the linked article, at https://code.google.com/p/drupalrewritefilter/ )
The instructions say to add the files to Eclipse, but I used Netbeans (just start a new project with existing sources).
You'll need to add the servlet.api.jar (some where on your system, if you have J2EE installed) and the UrleRewriteFilter.jar file you are using to the classpath for the build.
Place the resulting drupalrewritefilter.jar file and the UrlRewriteFilter.jar file you are using in WEB-INF/lib
Your WEB-INF/web.xml should have this filter directive:
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
<init-param>
<param-name>logLevel</param-name>
<param-value>TRACE</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Use this instead of the one the website for UrlRewriteFilter says to use.
NOTE: The Quercus install contains a DOCTYPE tag in the beginning for the Servlet API 2.2 or 2.3. But the <filter> tag is in the Servlet API 2.4 or higher. Your app will error-out unless you either link to a new Server API DTD or (and this is what I did) just delete the DOCTYPE tag all together.
Then you should have a WEB-INF/urlwrite.xml with:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN"
"http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
<urlrewrite>
<class-rule class="com.brianshowalter.drupalrewrite.DrupalRule" />
</urlrewrite>
Reload your drupal app, and then go enable clean URLS's