In my lab I was asked to create a simple website using JSF framework and use REST as well. I did some research on those two. It turns out that for REST I have to use JAX-RS framework with Jersey. I was wondering how can I integrate these two frameworks, JAX-RS and JSF?
I've already the below servlet in web.xml for JSF:
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/test/*</url-pattern>
</servlet-mapping>
For Jersey I figured that I have to use the below servlet in web.xml:
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>jersey.config.server.provider.packages</param-name>
<param-value>com.jbm.rest</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/api/*</url-pattern>
</servlet-mapping>
Now my concern is, to me it seems like this Jersey servlet will replace the Faces servlet in web.xml. This will change my application from JSF to JAX-RS. But I want to keep JSF and use JAX-RS as well. How can I do that?
This concern is unnecessary. You can safely have multiple servlets in a single web application, as long as their URL patterns do not clash with each other. Usually, if that were the case, a bit sane servlet container would already throw an exception during webapp's startup. In your case, you've registered the JSF servlet on /test/* (which is a strange, by the way, you usually use *.xhtml for that), and you've registered the JAX-RS servlet on /api/*. So you just have to call them using URLs matching those URL patterns.
And, to clear out a conceptual misunderstanding, you don't and can't "implement REST in JSF" at all. They are completely independent from each other. They can just easily run next each other in the same web application in all peace without knowing about each other. The only thing which they might share is the service layer or 'shared' (CDI) managed beans. But that's usually it. The design of the service layer is in turn independent from who's using it.
This specific problem is not related to JSF nor JAX-RS. It's just basic servlets. It might be as well worth the effort to take a step back to the basics and spend a bit time to learn more about the building stone of basically every Java EE web application.
You cannot directly have both in the same java class or layer.
I implemented it like below
|---> JSF Managed Beans(Inject logic here)
Database --> Daos --> Logic --|
|---> JAX-RS (Inject logic here)
Posting this for anyone trying to do this in XPages, there is a REST Control you can drop onto the page from the component library.
Like binding a ActionListener, you bind a java class to the component and set a url pattern.
See this note:
https://oliverbusse.notesx.net/hp.nsf/blogpost.xsp?documentId=2C4E
and sample app https://github.com/zeromancer1972/simplerest/blob/master/ODP/XPages/index.xsp
Related
I am a computer science student and have used Quarkus for several projects in the past year.
I recently received a new project where I have to create a rest API. Because I have to do a lot in a short time, I use Quarkus to easily do the job with RESTEasy for my web services.
But this API has to authenticate the user by using Apereo with protocols CAS or SAML2.
Moreover I have no experience in using Java security plugins.
I also searched about how to deal with that by using keycloak, Apereo Jboss client, Apero Spring boot client or by having a service along with Quarkus like a Tomcat that will do the authentication job. But I don't know which one would be the best and even which one would actually work.
Do you have any experience around that ?
Or what could I use to make my Quarkus API work with Apereo ?
Thank you very much for your time and help,
Best regards,
Thomas
Sorry for being late to the party, but I actually did a quarkus - apareo cas integration.
Basically I added quarkus-undertow extension to be able to use src/main/resources/META-INF/web.xml.
Also I used org.jasig.cas.client:cas-client-core:3.6.1 to have the cas filters.
And my web.xml contains something like this:
<context-param>
<param-name>serverName</param-name>
<param-value>${cas.redirect.url}</param-value>
</context-param>
<filter>
<filter-name>CAS Authentication Filter</filter-name>
<filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
<init-param>
<param-name>casServerLoginUrl</param-name>
<param-value>${cas.login.url}</param-value>
</init-param>
<init-param>
<param-name>ignorePattern</param-name>
<param-value>/proxy/</param-value>
</init-param>
<init-param>
<param-name>ignoreUrlPatternType</param-name>
<param-value>CONTAINS</param-value>
</init-param>
<async-supported>true</async-supported>
</filter>
<filter>
<filter-name>CAS Validation Filter</filter-name>
<filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
<init-param>
<param-name>casServerUrlPrefix</param-name>
<param-value>${cas.base.url}</param-value>
</init-param>
<async-supported>true</async-supported>
</filter>
<filter>
<filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
<filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class>
<async-supported>true</async-supported>
</filter>
<filter-mapping>
<filter-name>CAS Authentication Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>CAS Validation Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Saml integration is similar, just use the SAML filters.
For more information on configuration options, please see java-cas-client
Off topic, why do you need to authenticate a API via CAS? It redirects you to that CAS login window, then it redirects you back. you cant use this API via postman or curl. Also an API doesn't store any session about the user, so this redirect dance happens every time. This is not how API's are secured. Web pages or web applications yes, but not API's.
What's the most secure way to completely disable Cuba REST API, so that I can only use the Portal Module to manually expose endpoints?
You can simply remove rest_api servlet in web and portal (if exists) modules, i.e. delete the following lines from web.xml:
<servlet>
<servlet-name>rest_api</servlet-name>
<servlet-class>com.haulmont.restapi.sys.CubaRestApiServlet</servlet-class>
<load-on-startup>2</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>rest_api</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
Inside a web application, I have 2 web services and 2 servlets. Some of these components are internal so we don't want to limit them but one client facing web services needs to be limited because it can crashes the server if too many clients call it. I have been trying to do it in the web.xml as you can see in the code below with no success unfortunately. The JSP servlet in dispatch properly to the right work manager but the sample web services is going to the default work manager.
<servlet>
<servlet-name>Normaljsp</servlet-name>
<jsp-file>normal.jsp</jsp-file>
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>WorkManager-Global</param-value>
</init-param>
</servlet>
<servlet>
<servlet-name>Sample</servlet-name>
<servlet-class>com.mk.sample.WebServiceSample</servlet-class>
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>WorkManager-Endpoints</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Sample</servlet-name>
<url-pattern>sample</url-pattern>
</servlet-mapping>
How can I isolate this last sample web service with its own work manager ?
Thanks,
I am using IBM JAX-RS implementation to develop my REST APIs. I am looking to include validation of resource method parameters using Bean Validation (annotations) support provided in JAX-RS 2.0. I know that Jersey implementation supports this feature (https://jersey.java.net/documentation/latest/bean-validation.html). Is there a similar support available with IBM JAX-RS implementation on WAS 8.5.5? If so could you please direct me to some tutorial on how to accomplish this?
I am specifically looking into enabling and configuring Bean Validation support along with its integration with IBM JAX-RS.
Yes, WebSphere (both traditional and Liberty) will support bean validation with JAX-RS. But I am not aware of any tutorials. The code in the Jersey document that you referenced will work with WebSphere's JAX-RS/BV implementation.
To enable JAX-RS and Bean Validation in Liberty, your server.xml must contain the following features:
<featureManager>
<feature>jaxrs-2.0</feature>
<feature>beanValidation-1.1</feature>
</featureManager>
As an alternative, you could include some feature that includes those features (like webProfile-7.0 or javaee-7.0, but that may get you more function than you want).
Then, if you have your application packaged as an EAR or WAR file, you can copy it into your server's dropins directory, start the server and you should be able to run the example (the default HTTP port is 9080).
This link provides additional information about developing and deploying JAX-RS applications in WebSphere Liberty:
http://www.ibm.com/support/knowledgecenter/was_beta_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/twlp_dep_jaxrs.html
Hope this helps,
Andy
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I just heard about Apache Wink, and I was wondering what differences it had compared to Jersey or JBoss RESTEasy. What can be done in one that the other two can't?
We've been using Jersey for some of our internal projects mostly for it's simplicity, but I can't really figure out what makes these other two any better that I would consider switching. Does anyone have any use-cases for which niche each of these fills?
JAX-RS Implementations
Jersey
Reference Implementation
Usually the most cutting edge
Supports true asynchronous (ie web sockets etc...) connections through either Atmosphere or 2.0 version.
Has support for Spring and standard injection containers (ie #Inject).
Glassfish bundles it.
Its much more modular than the other JAX-RS projects.
It has a kick ass URI Builder
Does not necessarily require servlet container.
Grizzly support
Netty support (very early).
Swagger support
Sort of missing OAuth 2.0 . You'll have to use other libraries.
Some MVC support through Viewables
Hosted on java.net (a minus as the site is terribly slow at times).
Licensing is based on CCDL 1.1 and GPL-v2. Please make sure you check Jersey licensing before you use it for commercial use
https://jersey.github.io/license.html
RestEasy
Much of the above but most notable supports view technologies (see HTMLEasy)
It does have asynchronous connection support
Cache support
EJB support (if your into that crap)
JBoss bundles it (I think)
Netty support
Arguably the best Spring integration (MVC handler).
Early Swagger support
More security support including early OAuth 2.0 support
Apache Wink (never used it)
I have no idea why this project exists.
Supposedly its high performance focused.
It has a client built on top of HttpUrlConnection (which is a minus... it should be pluggable like Spring RestTemplate).
Basically Wink was developed in house at some enterprise companies and then given to Apache.
Requires a servlet container.
Restlet
Very powerful but very complicated
Provides some low-level REST support
Does not require a servlet container
Apache CXF
Some interesting WADL support.
Reuse and or combine JAX-RS w/ JAX-WS
Security support
Integration w/ Spring albeit kind of nasty
Supposed Autogeneration of client stubs
Other RPC-like systems
Message Queues
RabbitMQ
ActiveMQ
Asynchronous RPC
Finagle -- from Twitter.
msgpack-rpc
My humble opinion
I know the OP asked for REST but if this is for internal communication seriously consider using either a message queue or some other asynchronous RPC (Finagle) instead of traditional REST if your requirements match those systems.
If it must be classic HTTP REST (external) I would choose between either RestEasy or Jersey as a bulk of the mind share is put into those two projects.
Also see: Rest clients for Java?
When choosing the implementation to use have this in mind: if you try to deploy a Jersey web service to JBOSS 7.1, it will not work. This error will occur:
Only one JAX-RS Application Class allowed
This is because REST Easy comes bundled with JBOSS as the default JAX-RS implementation. So, JBOSS will decide that that's the implementation you want to use and will not load another JAX-RS implementation (like Jersey). In order to fix this, you need to add the following lines to your web.xml file:
<context-param>
<param-name>resteasy.scan</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.providers</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.resources</param-name>
<param-value>false</param-value>
</context-param>
Link: https://community.jboss.org/message/744530
One of my favourite Jersey extensions is Viewables. Viewables allow you to bind your data easily to a JSP page to implement a true Model-View-Controller (MVC) architecture:
http://blogs.oracle.com/sandoz/entry/mvcj
If you're going to use JBoss 7.x you must use RestEasy, 'cause it's integrated in JBoss. To use Jersey with JBoss 7.x, you have to disable RestEasy and it is complicated!