I am looking for a single sign on framework in java which supports Weblogic 10.3 and Jboss 4.2.2 and 5.1. JOSSO supports weblogic and jboss both but I am having lot of problems in weblogic (Session expiry issues, its not working on root context, different workflow for jboss and weblogic etc.). I am tired of JOSSO now. Please suggest me a stable SSO framework which works in jboss and weblogic.
What about an alternative like OpenID?
If you are able to use Spring security you can choose from several SSO options including CAS, Cloudseal and OpenId. A great benefit of Spring is that it sits at the application level (i.e. inside the WAR/EAR) and therefore eliminates many of the platform specific "gotchas" like the ones you are experiencing.
Of course if you aren't able to use Spring my solution is of little use! :)
Cloudseal includes a standard Java EE servlet filter which certainly works on JBoss (I have used it). I haven't tried it on Weblogic though.
Related
Can I deploy a Spring java application on all (or at least most) of JavaEE servers ? like Weblogic, JBoss, Webshpere, Tomcat, Jettty etc.
And is there is preferred Java EE server for Spring ?
Yes you can. And no - there isn´t. Errata: you can take a look at the SpringSource dm Server. Be aware that spring is not a java EE implementation. Read this post here.
Yes, you can deploy it on any server, and you can use it on standalone applications and even on mobile applications. It is in no way restricted to web deployment. It is not even restricted to java, there is Spring.NET and even a Python version. However, java and web servers are a common if not the most common use for it.
Currently recommended web server by VMWare/Pivotal (current owner of Spring) is VFabric tcServer, which is a Tomcat fork containing some extra tools and functionality. But server in itself does not matter, Spring is container agnostic.
There is no preferred EE server. VFabric tcServer is a servlet container, not an EE server. It contains "enterprise capabilities" instead, but that's not the same thing. As said however, you can use whichever EE server you want.
OpenShift offers the possibility to develop Spring based applications using JBoss EAP6. I am considering migrating a Spring application developed/deployed on Tomcat 7.
I have little experience with JBoss. Am I going to go through many troubles if I migrate my application? If yes which? Are Tomcat 7 and JBoss EAP6 compatible?
It depends entirely on your application.
The servlet container in JBoss 6 is based on Tomcat 6. If you are using any new features in Tomcat 7 (e.g. extensions in the Servlet 3.0 or JSP 2.2 spec), these will not run on JBoss 6.
The general response will be yes, JBoss will provide all the standard elments Tomcat does. But it is always possible to make it not compatible (using directly some tomcat class, JBoss Web use a different name space and there is no 1:1 corespondances).
I most cases you will need to make some litle addaptation (add some configuraiton and properties, change datasource name...).
JBoss AS7 documentation contains some Spring integration elements.
Some elments provided by default in JBoss may give you some trouble (like JPA), but if you have full controle on the application source, you should be able to get it working without lot of efforts.
Without inside on your application it will be difficult to give concreate effort estimate.
Since EJB 3 we have embeddable EJB containers, JPA implementations can be used without an application server, there is Weld for contexts and dependency injection and so on. Since on many systems is only Tomcat available, I wonder, if Java EE could be used without an application server but with a Servlet container like Tomcat.
What would I have to do to set up an Java environment? What drawbacks do you see?
Note that Tomcat is an Application Server. That said, in October we released Apache TomEE which is Tomcat with the missing JavaEE parts added, then Java EE 6 certified using the official TCK from Oracle.
The stack evolved from what used to be simply called "OpenEJB/Tomcat", which was a useful stack with a bad name :) Commonly overlooked because of the "EJB" part, meanwhile it also delivered Transactions, JMS, WebServices and more to Tomcat. The new name is far better and now it's officially certified like JBoss or GlassFish. We're pretty excited about its future.
If I understand well, you want to use EJB3/JPA within a servlet container.
There are not only stand-alone implementations of JPA, but also embeddable EJB3 container, such as OpenEJB or Glassfish embeddable container. So nothing prevents you from starting such an embeddable container from the Servlet container to use EJB3.
(Note: I don't know all the details about transactions. In a full-blown app. server, you have JTA and a distributed transaction manager. You don't have that in a Servlet container such as Tomcat. JPA works with JTA and plain JDBC, but I don't know exactly how an embeddable container work without JTA. Still, I guess that would work given that such embeddable containers are also meant for unit-testing where I guess there is no JTA distributed transaction manager.)
Another approach would be to use Spring. Spring and EJB3 have indeed become very similar. You can start the Spring DI container within the Servlet container and benefit more or less from the same facilities as EJB3 (declarative transactions, etc.). See this post about Spring vs. EJB3.
All these technologies have become pretty modular, especially with Java EE profiles. You can use Sevlets, EJB3, JMS, JPA, even JTA somehow independently of one other. You can also create an environment where you cherry pick the ones you would like, either with Spring or with Java EE. The question is when does it stop to make sense and rather use an app. server with everything available and easily manageable. I think Servlet/EJB3/JPA is the limit, if more is needed go for an app. server.
You will generally require some kind of container, even if that container doesn't provide Java EE-related services. After all, you do need a long-lived JVM process to host the code that you're executing. Tomcat and Jetty will do the job nicely, and in addition to basic servlet services, provide a few useful extras that will be relevant, like connection pooling.
J2EE without application server was introduced years ago by me (Guy Pardon, from Atomikos), with this seminal article: http://www.onjava.com/pub/a/onjava/2006/02/08/j2ee-without-application-server.html - focused on JMS and JDBC at the time.
In general it's easy to setup thanks to Spring and Hibernate. Actually, I got inspired to do this after doing a Java EE project and being confronted with the XML hell associated with app servers and EJBs. Without application server things suddenly became a lot simpler and more testable.
If you need a Tomcat installation then can be a bit more of a hassle to configure, but recently Atomikos has introduced out-of-the-box Tomcat integration as part of its commercial offering at http://www.atomikos.com.
HTH
I have an application that was written on JBoss 3.2.5 and I am tasked with migrating it to JBoss 5.
I am unable to deploy the application because it relies on JBoss MQ, which I read has been replaced by JBoss Messaging.
Is there any way I can get the app to work on JBoss 5 without making any code changes? Config changes are OK.
Actually JBoss Messaging is already being replaced by HornetQ.
In JBoss Application Sever 6.0, HornetQ will be the default messaging provider.
http://jboss.org/hornetq/
Is there any way I can get the app to
work on JBoss 5 without making any
code changes? Config changes are OK.
Assuming that your code is written to the JMS API, then yes, you probably can. However, don't underestimate how different JBossMQ is from JBossMessaging, the configuration is completely different.
Depending on how hard your app pushes the JMS API, you may get behavioural differences, but the odds are you'll be fine, as long as you can reconfigure JBossMessages within JBoss5 appropriately.
Another option is to move to JBoss 4.2, which still has JBossMQ, but is miles ahead of JBoss 3.2. Much of the functionality that JBoss5 gives you can be done with JBoss 4 (e.g. it has partial JavaEE 5 support).
JBossMQ will be replaced by JBoss Messaging in JBoss AS 5.0.
A good starting point to find out how to migrate would be JBossMQ
The company I work for sells a J2EE application that runs on Tomcat, WebSphere, or WebLogic. We have a customer that is trying to decide between Tomcat and WebSphere. They're leaning towards WebSphere because they're concerned that Tomcat has more security holes.
After searching around on the web, I've been unable to find any sites or studies that compare the robustness of the major J2EE application servers from a security standpoint.
Can any of you point me to information comparing app server security holes?
It's interesting that your client is "concerned that Tomcat has more security holes." I wonder if they could list what those holes are? If they can't, it's hearsay and FUD.
I would say that all web servers/servlet engines suffer from the same issues. It's the applications that are deployed on them that represent the real security holes. Cross-site scripting, SQL injection, lack of input validation, exposure of sensitive data due to poor layering and practices - these are all application issues that will be problems regardless of which app server you choose.
My personal opinion is that WebLogic is the best Java EE app server on the market. I don't have first-hand experience with WebSphere, but people that I respect who have tell me that it's a horror show. I've only used Tomcat for local development. It's never failed me, but that's hardly production experience. I have no idea how it scales.
I'd think carefully about Spring's dm Server, based on Tomcat, Spring, and OSGi. I have a feeling that it represents a future direction that all its competitors will be taking.
I'd say use tomcat over WebSphere if at all possible.
I think 99% of security is how you set it all up.
Are you also evaluating the security implications of Apache HTTP Server, IBM HTTP Server, and IIS?
Security involves so much more than just what application server you choose to run your webapp on.
Tomcat security report
Websphere security report (You have to dig into each update to see what was fixed)
In my experience, WebSphere isn't adding anything that isn't spec (and thus somewhat supported on Tomcat). The problem comes when trying to do some more complex security tricks (admin authentication using SecureID or something) you need to dig much deeper. WebSphere tries to put more of that in the UI Console.
That being said, your company should look at testing on Glassfish. It uses Tomcat as it's servlet container, but adds a much better UI for management.
According to this article, WebSphere community addition is no different than Tomcat 5.5 in terms of the servlet engine. In my opinion, this decision should be based on overall features needed rather than perceived "security holes".
Several different surveys have confirmed that Tomcat is running at over 60% of organizations worldwide, including the largest banks. As others have said, Tomcat security is not the issue. What "Plain Vanilla" Tomcat lacks is the console and UI which many enterprises require for access controls, diagnostics, monitoring, alerts and provisioning. Check out Tcat server from MuleSoft. It's 100% Tomcat (no fork), but has the enterprise capabilities for running Tomcat.
I can't say whether one is better than the other as I have never used Tomcat, and you really haven't defined what your security requirements are. Security can be a rather large beast and involve varying levels. So you will need well defined requirements to even determine what Security features are required.
We use Websphere integrated with several other IBM products to provide secure access to our application, which has been working well for us so far. You can look up Webseal and the Tivoli line of products for added security to WebSphere.