• code

Exposing a Managed Servlet Component As a Normal Servlet in ATG

If you want to run Servlets in your Oracle ATG Commerce application, there isn’t an easy way to expose them as Servlets AND take full advantage of the ATG component dependency and lifecycle system.

We’ve written a very simple Servlet Bridge which allows you to expose an ATG managed Servlet component as a normal Servlet via web.xml.

1. You write your Servlet class extending atg.nucleus.servlet.HttpServletService and treat it as a normal ATG component, configuring component properties, etc…. You put your Servlet logic in the service method. You configure it just like a normal ATG component.
2. You have our Sparkred ServletBridge class in your classpath.
3. You create an entry in your web.xml for each Servlet you want mapped. Each entry has a unique name, and points to the ATG component path of your Servlet class:


Very simple.

You can see the Sparkred ATG ServletBridge and use it in your own application.

2017-12-12T01:10:28+00:00April 30, 2014|All, Oracle Commerce Technical|

About the Author:

Devon has worked with Oracle Commerce for nearly two decades, and is also considered an expert in JBoss open source platform development. Since building one of the first well known Seam-based sites, 10minutemail.com, he has been repeatedly called upon to review manuscripts for Seam development books. Devon’s Oracle Commerce history traces back to 1998, when he worked at ATG as a senior ATG architect (later rebranded as Oracle Commerce) for both Professional Services and Sales Engineering. With all those years under his belt focusing on Oracle Commerce technologies, including work done for AT&T Wireless/Cingular, People’s Choice Awards, Scotts, and Ulta Cosmetics, Devon has proven his expertise in creating and maintaining high-volume Oracle Commerce implementations.


  1. Danylo June 3, 2014 at 10:22 pm - Reply

    Thank you Devon,

    I like this capability of ATG. Also we can use pipeline servlet for this task. I still think about drawbacks and advantages of these two approaches

  2. devon May 7, 2014 at 8:55 am - Reply


    you don’t create a component file for the ServletBridge class, but in the Servlet definition in the web.xml you point it to a ATG Nucleus component whose class extends the atg.nucleus.servlet.HttpServletService class. In my use cases those components have always been globally scoped, but there’s no reason you couldn’t use a request scoped target I guess? Generally global scope is typically best for action/logic components like you’d probably be using here….

    The ctx thing allows the ServletBridge class, a non-ATG component, to reference the ATG component of your choice.


  3. devon May 7, 2014 at 8:51 am - Reply


    sure! I wrote this for supporting HTTPS callbacks from PayPal as part of our ATG-PayPal integration module. So I needed to have a URL that would map directly to a service method in a component without a JSP, or form submission or anything like that. I wanted to get the request directly to a Java class. But I needed that Java class to be an ATG component with all the Nucleus magic and access to all my other components, so I didn’t want to write a basic Servlet for it, and do a bunch of JNDI lookups, etc…


  4. Danylo May 1, 2014 at 1:57 pm - Reply

    Interesting idea..
    Could you invent some example when technical approach which described above could be required instead of the standard mechanisms of ATG (droplets , form handlers, etc.) ?

  5. Naga May 1, 2014 at 6:31 am - Reply


    Thats a nice article.

    I remember using GenericServletService before for the same purpose. But do we need to create a component property file for this as mentioned? Are these started by Nucleus or by the J2EE servlet container as they are defined as servlets in web.xml ? If we are making properties files can they still have different scopes and stuff ? If property files is an option can we use them for dependency injection as against using the ctx:dynamo thing?


  6. Pranjal Pandey April 30, 2014 at 11:20 pm - Reply


    A nice article, I did something similar adding a new component for ServletPathDispatcher in the Request Pipeline.

    Creating a new component for OOTB ServletPathDispatcher and mapping my URIs to the component names, and writing the Droplets in the usual way (extending DynamoServlets).. I am able to expose my droplets this way.

    Thanks for the share! I liked the work you did on HttpOnly vulnerability and Paypal modules. double thumbs up for those :)


    • Elena May 1, 2014 at 4:46 am - Reply

      Thank you, Pranjal!

      I am glad you find our articles useful :)

Leave A Comment

Welcome !