For development of my first JSF 2.0 app I use GlassFish v3.1, deployment is planned on JBoss 6. Are there libraries which work on both servers and support JDBC based login? I have read about Apache Shiro, is this an option for this scenario or would you recommend a different library?
Shiro should more than meet your needs in a Java EE app. Feel free to ask any questions about it along the way - you'll find a helpful community!
Apache Shiro isn't based on Java EE security. I'd really use the latter (specifying security in web.xml, ejb annotations, ...). A login module in Glassfish (custom or existing one), or the jboss equivalent, should handle authentication/groups/roles. I really wouldn't use a non-standard library where there is a standard solution (=specification-based).
Related
How to call TWS beans from another Java EE server like JBoss or even WAS Liberty Profile?
I've no direct experience with JBoss or Liberty, but we have tried several times from Tomcat without success. Maybe it's possible with Liberty but as said I've never tried it.
This is one of the reason we are moving to REST APIs that makes interoperability much easier. REST APIs has been introduced on TWSd with 9.3 FP2, but are still not available on TWSz.
If you need them on TWSz, you can try to open an RFE to push this new feature.
If you don't have a product/release that natively support REST APIs, a possible pattern is to implement your own REST APIs based on J2EE APIs and deploy them as an additional WAR on the engine/connector WAS, and the call these REST APIs from your JBoss, Liberty.
Does GlassFish 4.0 server act as a SIP servlet container? I googled but could not find a answer. It may be obvious but I could not figure it out. I am new to Java EE.
I have got a legacy prototype implementation to work with. It uses Java SIP servlet. It's a Netbeans project. It does not have any setup documentation. So I don't know which server I should use.
I installed Netbeans IDE 8.0 with Java EE 7 and GlassFish server 4.0. I thought I would start learning to use SIP servlet by following Oracle's SIP Servlet Tutorial. In that tutorial, "Communication Server" is recommended in "Required Software" section. When I googled to download this, I found Oracle Communications Converged Application Server which was not free.
I'm not sure if you can use GlassFish for SIP servlets, I'm not aware of any implementation working with it. But you can use Mobicents, built on top of Tomcat or JBoss.
I have upgraded my web application to JAX-RS 2.0.
The web application seems to work fine on Apache Tomcat. However, it does not get deployed on Weblogic 12c (or even 10.3.6).
I am not sure if there is a proper support by weblogic and I believe it requires some configuration and class loader filtering to override the default JAX-RS 1.1 implementation ?
Any idea how to achieve this and make my web application run on WLS 12c ?
WebLogic 12c is Java EE 6 certified and so, implements JAX-RS 1.1. WebLogic plans to offer support for JAX-RS 2.0 in its next version 12.1.3 (as well a few other Java EE 7 APIs, but not all).
If you want to use JAX-RS 2.0 in current releases of WebLogic (12.1.1 and 12.1.2) you will have to deploy JAX-RS as you do with Tomcat, and tune weblogic.xml to isolate the classpath so it won't conflict with the JAX-RS 1.1 implementation.
For specifics on how to do this, please see documentation (of WebLogic 12.1.2): Updating the Version of Jersey JAX-RS RI
Update, Jan 4th, 2016
WebLogic 12.2.1, already released, is fully Java EE 7 certified.
WebLogic 12.1.3 will support JAX-RS 2.0 after registering Jersey 2.5.1 in the domain.
See the following page for details:
https://docs.oracle.com/middleware/1213/wls/RESTF/use-jersey20-ri.htm#RESTF290
I have a Web-Service that's being called from a remote Java program. I want to secure the Web Service with WS-Trust, using PicketLink. PicketLink is working, and I can obtain a token (assertion) from the picketlink-sts, using the WSTrustClient class.
But in JBoss 7, there appears to be no way to supply any of the client-side WS runtime classes with this token. The samples on the JBoss sites use this:
((BindingProvider) port).getRequestContext().put(SAML2Constants.SAML2_ASSERTION_PROPERTY, assertion);
But org.picketlink.trust.jbossws.SAML2Constants does not exist because there are no org.picketlink.trust packages in any of the JBoss 7 or PicketLink jars.
I have no experience with PicketLink (yet). But some Googling led me to this forum question & answer.
What advantages are there by going to Apache Shiro, and leaving Java EE's native APIs for security and session management?
I found that all security roles and sessions can be done in Apache Shiro but the same thing can also be done using Java EE security without any external dependency jars.
So suggest me some pros and cons of going to Apache Shiro.
I am biased of course (I'm a committer on the Apache Shiro project), so take this as you see fit, but here are my opinions:
Java EE Security does not support container-independent session clustering options out of the box (Shiro does).
Shiro was designed from its inception to work in POJO/Dependency Injection environments. It uses interface-driven design and provides many more hooks for customization than traditional Java EE security environments (e.g. how do you show how many users are currently logged in to your site with Java EE security? Shiro can help you show this).
Shiro is fully portable across any application environment. If you use Java EE vendor-specific security customizations, those would not be portable (e.g this StackOverflow question shows that switching to JBoss might solve the user's security problem - an unsettling answer IMO).
In the same vein as server-specific customizations, many Java EE security tutorials, articles and blog articles show you user-interface based configuration, which addresses things in different ways across platforms and can be frustrating to re-learn if you switch. Also, Java EE config often requires XML. I prefer a single, non-verbose text config format that I can use anywhere (shiro.ini is nice, but people also configure shiro with groovy, yaml, etc).
Shiro was designed to work in any application environment. Java EE security was designed, well - for Java EE only. At least when you learn Shiro, you can leverage that knowledge in any JVM-based application (Spring, Guice, Java EE, command line, etc), not just Java EE apps.
HTH!
Les