Skip to Content

In the part 1 of the series we have set up an EJB session facade with the Spring’s CCI utility code for communicating with the ABAP back-end via JRA adapter deployed and configured on the AS. In this post we will look at the way we can deploy the web front-end of the application based on JSF 2.0 reference implementation. In addition, we will try to use a popular UI components library for JSF, Primefaces.

The reason for this (unusual) combination of technologies, is that NW 7.3 supports only JSF 1.2 out of the box, with a custom UI components library for the SAP look-and-feel. However, the JSF technology has greatly progressed since the JSF 1.2 edition, and the multitude very useful UI components libraries have been created for developing the UI with this technology. Here are some of them: Tomahawk, Richfaces, Primefaces, IceFaces, just to name a few. For our proof-of-concept I have chosen a popular combination of Mojarra JSF 2.0 implementation combined with Primefaces library.

Now available part 3 of the series. Source code is available on GitHub nw-jsf-showcase.

Deploying Mojarra to the AS

First we need to substitute the JSF 1.2 library used by default by the AS with the Mojarra 2.1.7 implementation of JSF 2.0. I’m reproducing below the steps described by Schindler Ingo in the forum post: JSF2 on Netweaver 7.3 (see the correct answer, and the remark at the end of the thread about “gzip-compression of the AS”), whose insight proved invaluable in this task.

Another very interesting article by Goran Stoiljkovski explains well how the AS resolves classpath dependencies and what is needed to deploy an application using so called heavy resource loaders. After several attempts, I settled on the Ingo’s proposed method of deploying and referencing Mojarra as a library on the AS.

Download Mojarra library JAR. I chose javax.faces-2.1.7.jar, the latest at the time of the writing of this post. Create a simple General –> Project project in the NWDS workspace. Add the following files and folders to the project (Ingo’s suggestion):

What we are doing here is creating by hand  the contents of the SDA file (mojarra217.sda) which will contain our JSF 2.0 library in order to deploy it to the AS. Later our application’s EAR will reference this (deployed) library in it’s application-j2ee-engine.xml descriptor. The easiest way to go about creating such SDA is to locate any library SDA already deployed on the AS, copy it locally, change the extension to .zip and unzip it. Then all the one needs to do is to adjust slightly the contents of the relevant files. Another way is to create the library SDA using the batch script make_SDA.csh found in <path_to_java_instance>/j2ee/deployment/scripts directory on the server. Look at ReadMe.txt for usage guidelines, and or templates in the same directory.

Here are the contents of the SDA’s files shown above:


<application-j2ee-engine xmlns:xsi="" xsi:noNamespaceSchemaLocation="application-j2ee-engine.xsd">

Provider name is arbitrary, but you should be consistent throughout the SDA.


Manifest-Version: 1.0
Implementation-Title: javax~faces~2.1.7
Implementation-Version: 1
Implementation-Vendor-Id: local.j2ee
Specification-Vendor: SAP AG

Notice the Implementation-Title and Implementation-Vendor-Id entries.


Manifest-Version: 1.0
Ext-SDM-SDA-Comp-Version: 1
softwaretype: library
JarSAP-Standalone-Version: 20090803.1000
JarSAPProcessing-Version: 20090907.1000
deployfile: sda.xml
archivetype: DC
keyname: javax~faces~2.1.7
keyvendor: local.j2ee
keylocation: Deployment Manager
keycounter: 1
componentelement: <componentelement  name="javax~faces~2.1.7" vendor="local.j2ee" componenttype="DC" subsystem="NO_SUBSYS" location="Deployment Manager" counter="1" deltaversion="F" updateversion="LB-20120413181800" componentprovider="Deployment Manager" archivetype="DC"/>
JarSL-Version: 20100616.1800
compress: true

Notice the softwaretype, keyname entries and the name and vendor attributes in the componentelement.


<engine-deployment-descriptor version="2.0">


    <engine-deployment-descriptor version="2.0" />

Standard content for SDA deployment descriptor.


<!DOCTYPE provider-descriptor SYSTEM "library.provider.dtd">
        <reference type="library" strength="weak" provider-name="">servlet</reference>

Hint: one can find DTD files useful when creating some of these XML files by hand in <path_to_java_instance>/j2ee/cluster/server0/dtd directory on the AS.

Zip the project root directory and rename the resulting file with .sda extension (mojarra217.sda). You can now deploy the resulting SDA to the AS using Deploy View, External Deployable Archives.

Using the steps from Goran’s article we can now check if the library was successfully deployed on the AS. Use SAP Management Console of NWDS to find out which is the port for the telnet on your AS, by looking at the Access Points, usually it is 50008. Login to the telnet using the administrator account. Use the command to list the library loaders of the AS (see man LL for help).

If you see your library listed with library: prefix then it was successfully deployed to the server.

Creating JSF 2.0 Dynamic Web Project

Now we are ready to create and deploy the web module of our application which will use the above Mojarra library and Primefaces UI componet library.

First we need to create a User Library in NWDS with the javax.faces-2.1.7.jar, this will be needed during JSF Facet selection of our Web project. For this, go to Preferences –> Java –> Build Path –>User Libraries and create new user library adding the Mojarra JAR to it.

Create new Dynamic Web Project. In the Configuration group, choose Default Configuration for SAP Libraries and click Modify button. Add JavaServer Faces 1.2 facet to the project (we will later change the JSF version by hand). Do not forget to add the Web project to the EAR project created in part 1 (tmp~sflight~ear).

When prompted to specify JSF capabilities, deselect the SAP Component Library for JSF and select the Mojarra user library you’ve created previously. This is needed only for compilation (access to javax.faces.context.FacesContext, etc), since at runtime it is the library deployed on the AS that will be used.

Once the project has been created it should have the following structure (with some of the files which will be added later) :

The project needs to reference the EJB and Java modules created in part 1. For this go to the project Properties –> Java EE Module Dependencies and select the EJB and Java modules. Now the Web module should have compile-time access to EJBs and DTOs.

We need to modify the web.xml file.

<web-app xmlns:xsi=""
    xmlns="" xmlns:web=""
    id="WebApp_ID" version="2.5">
<!-- Configure listener for Spring web application context -->
<!-- Your default application web page, index.xhtml, for example, see example below -->
<!-- Faces servlet and mapping of xhtml pages -->
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-name>Faces Servlet</servlet-name>

The only non-standard entry in this file is the reference to Spring’s web application context loaded from the WEB-INF/applicationContext.xml. This file contains the jndi-lookup reference to the local stateless session EJB from the tmp~sflight~ejb project which will be deployed in the same EAR. We can find the exact JNDI name of the EJB using the technique described in part 1.


<beans xmlns=""
    xmlns:xsi="" xmlns:p=""
        Look up JraManagerBean EJB from the the JNDI   
    <jee:jndi-lookup id="jraManager"
        jndi-name="" />

We now modify faces-config.xml file to manually set the version of JSF to 2.0.


<faces-config xmlns=""
<!-- application, converters, etc... -->

We now are ready to create some views (xhtml pages) and corresponding JSF managed beans. For example, is shown below

//JSF 2.0 allows for annotation-driven specification of managed beans
public class SearchFlights implements Serializable {
    private static final long serialVersionUID = 1L;
    private static final Location loc = Location
//we need to manually retrieve this bean from the application context, see init() method
    private transient JraManagerLocal jraManager;
    private String airlineId;
    private String destFrom;;
    private String destTo;
    private Collection<FlightData> flights;
//getters and setters are omitted
//will be executed once the bean has been initialized
    private void init() {
        jraManager = Utils.getBean("jraManager", JraManagerLocal.class);
//action event called from the view
    public void search(ActionEvent event) {
                        "Search for flights with airlineId {0}, destFrom {1}, destTo {2}",
                        (Object) airlineId, (Object) destFrom, (Object) destTo);
        try {
            flights = jraManager.searchFlights(airlineId, destFrom, destTo);
            SimpleLogger.trace(Severity.DEBUG, loc, "Found {0} flights ",
                    (Object) flights.size());
            if (flights.size() == 0) {
                                "info", "no_flights_found"));
        } catch (BapiException e) {
            flights = null;
            Utils.processBapiErrors(e, loc);

The reference to the EJB has to be wired manually since we have chosen to let the JSF manage the scope of our beans, and so we cannot use @Autowired mechanism of Spring DI. You might be asking why didn’t I just annotated the EJB reference with @EJB annotation, following the standard pattern. The problem is that when we deploy the EAR we will see the following error (which can be ignored).

May 2, 2012 3:20:32 PM com.sun.faces.spi.InjectionProviderFactory getProviderFromEntry
SEVERE: JSF1051: Service entry '' does not extend DiscoverableInjectionProvider.  Entry will be ignored.

This error is expected since, the registered with Mojarra JSF 2.0 implementation does work with the default mechanism for EJB injection provided by the AS out of the box and configured for JSF 1.2. But to retrieve a been from the Spring’s web application context is rather simple in the context of the JSF managed bean, we can use for this purpose.

public class Utils {
     * Retrieves a bean with id given by <code>beanName</code> from current {@linkplain WebApplicationContext}.
     * @param <T> any type
     * @param beanName id of the bean
     * @param beanClass type of the bean
     * @return typed bean from the application context
     * @throws IllegalStateException if application context could not be retrieved
     * @throws BeansException if the bean with the given id could not be found
     * @throws ClassCastException if the retrieved bean cannot be cast to the provided type
    public static <T> T getBean(String beanName, Class<T> beanClass) {
        WebApplicationContext appContext = WebApplicationContextUtils
                .getWebApplicationContext((ServletContext) FacesContext
        if (appContext == null) {
            throw new IllegalStateException(
                    "Cannot retrieve Spring web application context");
        return beanClass.cast(appContext.getBean(beanName));

Adding Primefaces UI component library

The real added value of all the work done above, comes with the ability to use third-party UI component libraries for JSF 2.0 framework. There is multitude of them, most of them are free or open-source and they allow for high quality, professional UI creation based on some leading edge client side scripting technology available. This not to mention the obvious advantages of using JSF 2.0 with it’s improvements to navigation, AJAX support, and Facelets.

Note: Chris Hesse reported the issue with faces-config.xml validation to Primefaces. It should be fixed in 3.5.x and 4.0 branches, see the comments after this post.

To add Primefaces UI components library, you normally just need to add it to the set of Web App Libraries of the Web Project located in WEB-INF/lib directory. I’ve tried with primefaces-3.2.jar but got a following error during deployment.

[JLinEE reported following erros for application.
 * JSF Application Test: cvc-complex-type.2.4.a: Invalid content was found starting with element 'source-class'. One of '{"":system-event-listener-class}' is expected., file: tmp~sflight~web.war#META-INF/faces-config.xml, column 27, line 17

Apparently, the AS cannot validate the faces-config.xml packaged with the Primefaces JAR. But this is relatively easy to correct. You need to extract the contents of the primefaces-3.2.jar archive and edit the META-INF/faces-config.xml file. It need to be valid with respect to the declared javaee schema. This is just a matter of rearranging the order of some elements, for example, a system-event-listener element on the line 16 is


but should instead be


Once the validation errors are corrected, you can repackage the contents of the Primefaces JAR, which is now ready to be included as part of Web App Libraries of the project. To test if Primefaces are working you can use a simple index.xhtml page. If everything works well, you will be able to see the spinner UI component.


<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns=""
        <p:spinner />

One more thing is needed for Primefaces to work on the AS. As Ingo mentions at the end of this forum post, we need to set the CompressedOthers property of HTTPProvider to false. Otherwise Primefaces will hung (until the connection timeout) trying to access some resources. For this login to /nwa interface with administrator, go to Configuration –> Infrastructure –> Java System Properties. Select Services tab and search for HTTP Provider. Set the CompressedOthers property to false (if needed). You might need to restart the AS for the changes to take effect.

Deploying the application

Before you deploy and run the application, you need to reference Mojarra JSF 2.0 library we deployed on the AS in the EAR’s application-j2ee-engine.xml file.

        This is the reference to the JSF 2.0 library,
        notice the prepend="true"
    <reference reference-type="hard" prepend="true">
        <reference-target provider-name="local.j2ee"
        This is only needed if you use
        in tmp~sflight~java, see part 1
    <reference reference-type="hard">
        <reference-target target-type="application"
        Cange to match your provider name

At this point, it is likely that NWDS will complain that the XML file is invalid. You can disregard the error, but if you want to remove it, you can add an inline DTD declaration with prepend attribute specified as legal attribute of reference element.

<!DOCTYPE application-j2ee-engine [
<!ELEMENT application-j2ee-engine (reference*, classpath?, provider-name?, modules-additional?, fail-over-enable?)>
<!ELEMENT reference (reference-target)>
<!ATTLIST reference reference-type (hard|weak) #REQUIRED>
<!ATTLIST reference prepend (true|false) #IMPLIED>
<!ELEMENT reference-target (#PCDATA)>
<!ATTLIST reference-target target-type (application|library|service|interface) #REQUIRED>
<!ATTLIST reference-target provider-name CDATA #IMPLIED>
<!ELEMENT classpath (#PCDATA)>
<!ELEMENT provider-name (#PCDATA)>
<!ELEMENT modules-additional (module+)>
<!ELEMENT module (entry-name, container-type+)>
<!ELEMENT entry-name (#PCDATA)>
<!ELEMENT container-type (#PCDATA)>
<!ELEMENT fail-over-enable EMPTY>
<!ATTLIST fail-over-enable mode (disable|on_request|on_attribute) #REQUIRED>

Once you’ve deployed the application, you should check the loaders for the application using telnet interface.

The reference to the library:local.j2ee~javax~faces~2.1.7 should be listed in the list of Direct Parent Loaders, and it should figure above the EAR’s library loader, since we specified the prepend=”true” in the application-j2ee-engine.xml file for this reference.

Summary of part 2

You should now have a working JSF 2.0 web application with Primefaces. You can use JQuery Themeroller to create a custom theme for the UI components of Primefaces which goes well with SAP look-and-feel. I’ll try to add some screenshots of the application running on the AS portal soon.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Schindler Ingo


    I’m experiencing a stange behavoir while deploying my application to the AS.

    The deployment tooks every time more or less exactly 6:30min no matter how much classes or xhtmls there are in the project.

    Even an empty project, just the libs, takes so long. My first guess was, that some XML is trying to call home which is forbidden for the AS (access to the internet is restricted).

    Can someone verify that?

    P.S.: Thank you for mentioning me in this Post 😉

    1. Werner Schaubmaier

      Hello Ingo,

      thank you for your great work and effort to enable us using JSF2.0 and Primefaces on WebAS NW7.3 !!

      I’ve been able to deploy a working example following the steps above.

      But as you mentioned, i’m experiencing the same effect while deployment as you did. The deployment takes very long time.

      Did you find a solution for this problem till now ?

      Thank you


      1. Chris Hesse

        The issue here if I had to guess is a proxy issue.  During the XML validation that the SAP Netweaver deploy service does during the deploy, it goes out to the internet to get the XSD for the various XML files.  The timeout is probably what is taking so long.

        In my case, I set the proxy directly on the java server to match my company’s proxy settings and now the deploy is fine.

        Configure System Proxy:

        Navigate on your host machine to http://<server&gt;:50000/nwa/app-modules and search in the name field for the application Click on the row, and then click on the “Proxy” service below.


        See the following link for additional details

        Overwrite JVM Settings: true

        HTTP Proxy Host:  <YOUR_PROXY_HOST>

        HTTP Proxy Port: <YOUR_PORT>

        HTTP – Enable Proxy Setting: true

        Repeat the same for all of the HTTPS variables. Restart the service|http and|proxy, or simply restart the cluster.



        1. Werner Schaubmaier

          Hello Chris,

          thank you for this prompt reply. I configured the proxy settings on the server according to our customers need and your advice above. After restarting the cluster the deployment works fine ( now 30s , before 9 min  ). This was a great support for me and i can go on now !

          Thank you again


  2. Alan Rubin

    Hi George,

    First thank you very much for the great article !

    I have basically the same architeture that you have defined (but with Jersey and Spring-MVC instead of JSF and heavy libraries deployment instead of deploying Spring within the war), but unfortunatelly I’m getting java.lang.NoClassDefFoundError: javax/resource/cci/Connection exception when deploying the application (see log below). Do you have any clues ? It seems that apart from tc~bl~jra~api runtime reference other reference is needed.

    Also where can we have the source code for the application ? I cannot find it attached to this article….

    Thanks you very much !


    —- The exception when deploying

    Warning occurred on server 4392650 during startApp of : (Failed in component:, ) Initialization of servlet [mvc-dispatcher] failed. Check init() method of servlet. Error is: [org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘jraManagerBean’: Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.test.disti.dao.CustomerDAO com.arm.disti.ejb.JraManagerBean.dao; nested exception is java.lang.NoClassDefFoundError: javax/resource/cci/Connection]

    1. George Ushakov Post author

      Hi Alan,

      Sorry for a late reply… I was busy with some other stuff lately.

      I checked in my configuration I only have dependency on tc~bl~jra~api in my

      application-j2ee-engine.xml (EAR module) :

      <reference reference-type=”hard”>

              <reference-target target-type=”application”



      But when I check the dependency of the deployed application on the server (Deployment perspective) I see that it depends in the other stuff and I guess that the CCI libraries get loaded then.

      About sources, I didn’t know I could attach it to the post. I’ll see if I can do it.


  3. Vishweshwara P K M

    Hi George,

    I am trying to implement this demo and am facing some issue. Request you to, help me in sorting it out.

    I have followed all the steps (excluding the Spring part, as i am not hitting the backend as of now). When I run the application, i don’t get any error, but the blank page is getting displayed. View source shows all the tags in the page as is. I am Using NWDS 7.3 SP04.

    Please help.

    Thanks & Regards,

    Vishweshwara P.K.M.

    1. Alan Rubin

      Hi Vishweshwara,

      I was able to run the example, but my application is slightly different.

      Please check your NW logs for exceptions and create a discussion at SCN with the logs. Publish the link here and I will try to help you from there.



  4. Ashwin Kulkarni

    Hi George,

    While trying to implement JSF 2.0 in NWDS 7.3, I am facing an issue while deploying the sda file. I have followed the exact steps as given in the document, but when i try to add the sda in Deploy View i am getting the below exception:


    Error while loading archve D:\NWDS CE 7.3\Workspace\JSFMojarra2.1.sda.

    The specified file D:\NWDS CE 7.3\Workspace\JSFMojarra2.1.sdais not a valid SAP deployable unit. In case it is Java Enterprise application, please use import feature of Deploy View.

    Additional information:The information about the development component found in the manifest is either missing or incomplete!

    Manifest attributes are missing or have badly formatted value:

    there is no deployment descriptor declared

    (D:\NWDS CE 7.3\Workspace\JSFMojarra2.1.sda)

    Please tell me if i am missing anything.



    1. George Ushakov Post author

      Hi Ashwin,

      I double checked the files which I have listed (see the image in the post for mojarra217) they are exactly as I have posted. The only difference is that when you copy paste the code it gets tabulated once creating the extra space on the left, could this be a problem?

      Looks like your AS does not like the sda-dd.xml (deployment descriptor) file, can it be that it’s missing or not properly structured?

      You should also double check all respective entries in the provider.xml, application-j2ee-engine.xml, MANIFEST.MF, SAP_MANIFEST.MF (pay attention to component-name, provider-name, Implementation-Title, Implementation-Vendor-Id, keyname, keyvendor, and the name and vendor attributes of componentelement in these files). These entries should be consistent and match the version of javax.faces JAR which you are deploying.

      Deploying a heavy resource library to the AS is not an exact science, unfortunately I did not find any easier way, than to package the SDA for the library by hand. My advise, is to find any successfully deployed library SDA on the AS itself (using an SSH account on the server, see <AS_SYSTEM_PATH>/J00/j2ee/j2eeclient directory for example) copy it locally, unzip it and inspect the corresponding configuration files. These, especially sda-dd.xml can be version dependent.

      There are some build scripts in the <AS_SYSTEM_PATH>/J00/j2ee/deployment/scripts directory on the server, you can check out the ReadMe.txt and use make_SDA script to create an SDA from a provided JAR, then you can also unzip it locally and see if there are any differences with the files that I have posted.

      Good luck,


      1. Ingo Taraske

        Hi George,

        first thanks for the great article series.

        I’m having the same issue as Ashwin. I then followed your advice and downloaded a working SDA file from the AS: tc~je~ejb~client~730.sda. Then I noticed the following: the downloaded file can be added in Deploy View without an error, but when I extract it, then ZIP it again and rename the extension to .sda and try to deploy the new file the error posted by Ashwin appears.

        Any ideas?



  5. Chris Hesse

    Hi George,

    Thank you so much for this post, it was extreemly helpful!

    FYI – I reported the faces-config.xml validation issue in the Primefaces forum.  The fix was merged into their mainline 4.0 branch, as well as back ported to their 3.5.x elite branches within 2 days!

    For the future, primefaces applications will deploy on Netweaver servers without having to manually edit the jar file.

    I have been extreemly impressed by the primefaces community and development support, I encourage everyone to contribute to this project!



    1. George Ushakov Post author

      Hi Chris,

      Thank you for the feedback. Glad this could help. It’s nice to have the faces-config.xml from Primefaces to validate, thanks.

      Good luck,


  6. Chris Hesse

    Here is an important tip!

    SAP Netweaver 7.4 is not “JSF ajax aware”, in that the 1.2 version it ships with doesn’t have ajax built in.  When using 2.1.29 Mojarra as I am, (or any 2.0+), after the session expires, the ajax requests triggered from a user seem to “do nothing”.  This is because there is an SAP provided AuthenticationFilter which redirects requests to the logon page.  It does the same for ajax requests, and of course the application doesn’t know what to do with an HTML logon page response from an ajax request.  The solution is to create an override of the SAP provided filter and configure it in your application.

    My question and answer with more details can be found here:;

    I’d also say, if you are doing JSF2+ development, make sure you include the amazing Omnifaces library to your project, it solves SO many issues!  Keep in mind, the 2.0+ versions of Omnifaces are for Servlet spec 3.0, so we must stay on the 1.x branch (1.11 is the latest as of 9/16/2015).

    I hope this helps someone else! 🙂

    1. Rolf Paulsen

      Hi Chris,

      this sounds really awesome and is very helpful, probably identically for 7.5.

      Maybe we make it to upgrade Netweaver to Servlet spec 3.0?




Leave a Reply