1

Just curious whether it is possible to run JSF 2.3 on IBM Domino?

I have tried to deploy (JSF versions 2.0, 2.1, 2.2, 2.3) via the UpdateSite Plugin install following Sven's post HowTo: Vaadin on Domino. But was not really successful as got the following exceptions (listing from v2.3, but other versions are similar):

Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory. Attempting to find backup.
Uncaught init() exception thrown by servlet {0}: {2}
CWPWC0005E: Error occurred while initializing servlet wrapper. javax.servlet.ServletException: Uncaught initialization exception thrown by servlet Thread[Thread-6,5,main]
CWPWC0005E: Error occurred while initializing servlet wrapper. javax.servlet.ServletException: Uncaught initialization exception thrown by servlet

Any suggestions what to adjust? I do understand that Servlet version could not match JSF spec, but is it feasible at all? Thanks!

AndrewG10i
  • 661
  • 1
  • 6
  • 21
  • Looks like IBM Domino 9.0.1 implements Servlet 2.5, so theoretically JSF 2.2 should work (except fileUpload control). There is another issue: looks like IBM Domino has embedded JSF 1.1 libs (have found jsf-impl.jar and jsf-api.jar), so probably this potentially could create classpath chaos... – AndrewG10i Jul 01 '17 at 06:04
  • 1
    Why? Is there something specific you miss, what makes you want to hack Domino? I mean, it's completely fine to try it. But remember: you will get no support from IBM when in trouble with your customer. – Frantisek Kossuth Jul 04 '17 at 10:17
  • The main purpose of this exercise: is completely migrate XPages app to pure JSF/PrimeFaces/Java7EE/JRE8/GlassFish, so this is one-way-ticket. But in order to achieve smooth migration of XPages - it would be super helpful to have functional project and perform migration XPage-by-XPage to JSF/PrimeFaces xhtml pages. I am almost done with NSF data migration to MongoDB, thus only UI is pending... – AndrewG10i Jul 04 '17 at 10:25
  • I see no point to force Domino to host your new application. – Frantisek Kossuth Jul 04 '17 at 14:00
  • The point is the transition period only, during the actual XPages rewrite process to JSF pages. Then application is to be hosted by GlassFish. This is not my first migration from XPages and based on the experience it is much easier to perform migration when you have more or less stable app. – AndrewG10i Jul 04 '17 at 14:34
  • 1
    @Frantisek: Servlets and OSGi were designed for that purpose. – Sven Hasselbach Jul 05 '17 at 21:21

1 Answers1

1

The short answer: don't bother

The long answer: Domino modified quite some number of OSGi elements to run. The Domino JSF has been extended to include SSJS. So you fight with a lot of moving parts.

What you want to do:

  • put an nginx in front of your Domino on 80/443
  • run Domino on a different port only accepting 127.0.0.1 connections
  • run your Primefaces Websphere liberty Glasfish app on yet another port
  • have nginx redirects point to old/new server based on url

Users will see one server, https can be handled by nginx, you can have http2, offload static resources.

While you are on it: give vert.x a shot. Way more fun than JEE

stwissel
  • 20,110
  • 6
  • 54
  • 101
  • Please keep in mind that you should ask the admins first if such a solution is possible. The most companies which I am working for have a strict policy about installing other technologies on their production environment. And check who is responsible for maintainig updates / security relevant topics before mixing technologies. In my experience this is a no-go for most companies. And I am praying for years now, especially for easier SSL deployment with nginx. Also, you will have more problems to keep your application stable, there are more points of failure if more components are involved. – Sven Hasselbach Jul 07 '17 at 11:51
  • Stephan, Sven, thank you so much for your posts, probably I would follow the recommendation “don't bother”. ) Concerning the migration itself and mixture of the technologies: absolutely agree with all concerns, but as we need to get full control over the application due to several reasons (scalability, performance, availability of new technologies, open-source commonly used platform, and finally licensing) - decision was taken to migrate from IBM XPages… – AndrewG10i Jul 11 '17 at 11:33