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:
<servlet> <servlet-name>MyAwesomeServletBridge</servlet-name> <servlet-class>com.sparkred.ServletBridge</servlet-class> <init-param> <param-name>loggingDebug</param-name> <param-value>false</param-value> </init-param> <init-param> <param-name>destinationServlet</param-name> <param-value> ctx:dynamo:/com/myapp/servlet/AwesomeServlet </param-value> </init-param></servlet><servlet-mapping> <servlet-name>MyAwesomeServletBridge</servlet-name> <url-pattern>/servlets/awesome</url-pattern></servlet-mapping> |
Very simple.
You can see the Sparkred ATG ServletBridge and use it in your own application.
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
Naga,
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.
Devon
Danylo,
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…
Devon
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.) ?
Hi,
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?
-Naga
Hi,
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 :)
regards
Pranjal
Thank you, Pranjal!
I am glad you find our articles useful :)